Технология IT-консалтинга растет

Технология IT-консалтинга растет

Михаил Токарев Партнер, Петербург

Рынок одолжений IT-консалтинга растет. Компании выстроились в очередь к консультантам за ERP-совокупностями, но вот как верно подойти к внедрению, знают единицы.

В Российской Федерации В первую очередь XXI века начался резкий рост IT-рынка по большому счету и консалтинговых одолжений в данной сфере в частности. Все больше консалтинговых компаний входит в рынок консалтинговых одолжений, предлагая собственный видение и инструментов (ПО), и разработок производства. И не обращая внимания на кризис до «перегретости» рынка еще далеко, поскольку спрос существенно опережает предложение.

В кризис клиенты стали искать более недорогие предложения, но необходимость в одолжениях наряду с этим не уменьшилась.

На фоне растущих количеств одолжений сам предмет приложения упрочнения этих компаний остается не хватает стандартизованным, а большая часть компаний и вовсе не придают значения подобным «мелочам». В случае если мы посмотрим дискуссии на тему: главные неточности при внедрении информационных совокупностей, мы везде заметим среди них и отсутствие у компании-внедрения методики и консультанта проектирования. Это и ясно.

Платить много тысяч долларов за хаотически продвигающийся проект никто не желает.

Многие же консультанты уверены в том, что достаточно изучить инструментальное обеспечение (Микрософт AX, SAP, ORACLE) и предприятия-клиенты выложат каждые деньги за их услуги. Страно, но и клиенты отбор консультантов выполняют, первым делом, исходя из их знаний продукта.

Цель разрешённой статьи – предложить выходы из данной ситуации, оказать помощь консалтинговым компаниям сделать проектные работы более технологичными. Для представления разработки, понятной практически всем ее пользователей, нужно сперва выяснить понятийный аппарат. И тут разумеется нужно применять только стандартизованные термины.

Так как никто не сооружает строения без ГОСТ и СНИП. АСУ не меньше сложные совокупности, чем строения, но считается, что они не так страшны для жизни, соответственно, вероятно забыть про стандарты.

О терминологии

Понятийный аппарат современных консалтинговых одолжений так размыт, что ненужно спорить с авторами, по-различному трактующими термины MRP, ERP, КИС и т.п. Увидим лишь одно: имеется стандартизованный в Российской Федерации термин АСУ (автоматизированные совокупности управления), подмножеством которых, по определению, являются ERP-совокупности. Но термин КИС, употребляемый сплошь и рядом, кроме того в некоторых производных стандартах, не выдерживает никакой критики.

Так как информационные совокупности внедряются не только в корпорациях (в случае если трактовать его как корпоративные информационные совокупности).

В контексте данной статьи мы будем применять установленные стандартами термины, представленные ниже.

АСУ – целостная организационно-техническая совокупность элементов (информационной инфраструктуры, регламента и персонала) снабжающих исполнение автоматизированных информационных процессов, связанных неспециализированной функциональностью, целевым назначением и информационными потоками. Это термин, выяснен в Лит. 1 и не имеет смысла никак по-второму его определять.

В зарубежных стандартах данный термин определяется как «информационные совокупности» (ISO 12207). По большому счету говоря, зарубежные стандарты достаточно вольно трактуют термины, но термин «информационные совокупности» в точности повторяет определение АСУ, данное в ГОСТ 34 серии еще в 70-х годах прошлого столетия.

Инфраструктура – взаимосвязанная совокупность средств технического, программного и информационного обеспечения, представленная в виде иерархической послойной структуры объектов, снабжающих исполнение всех установленных функций АСУ. В инфраструктуру входят следующие совокупности элементов по слоям: прикладной (приложения), информационный (БД, СУБД), вычислительный (сервера, рабочие станции и т.п.), транспортный (сетевое оборудование, оборудование передачи информации и т.п.), физический (кабельные совокупности, совокупности бесперебойного питания, кондиционирования и т.п.).

Совокупность – совокупность сильносвязанных элементов, владеющая минимум четырьмя особенностями:

  • Целостность и членимость – это целостная совокупность целостных элементов, любой из которых вероятно разглядеть как отдельный элемент;
  • Связность – значительные и устойчивые связи элементов между собой превосходят по силе связи этих элементов с другими сущностями, не входящими в данную совокупность;
  • Организация – энтропия совокупности меньше суммы энтропий входящих в нее элементов;
  • Интегративность – у совокупности имеется такие качества, каковые не свойственны ни одному из ее элементов в отдельности (лит. 7).

Составляющие разработки

Каждая разработка включает в себя инструменты производства и методику работ, снабжающие это производство.

Для консалтинговых компаний методикой есть совокупность документов, обрисовывающих:

  • жизненный цикл работ, начиная от предпродажной подготовки и заканчивая сопровождением создаваемых совокупностей;
  • процедуры (процессы) обеспечения качества работ;
  • процедуры (процессы) управления проектами;
  • документацию, которая предоставляется клиентам на протяжении работ, и внутренняя проектная документация.

По большому счету говоря, стандарты серии CMM требуют на каждом уровне «завершенности процессов», еще около десятка процессов, снабжающих внедрения производства (и процесс проектирования). Но в Российской Федерации эти процессы, в большинстве случаев, не выделяются в отдельные, а выполняются в составе главных. К примеру, процесс управления требованиями должен быть выяснен очевидно (для определения процесса нужно выяснить состав функций/подпроцессов, обладателя процесса, входной и выходной потоки, свойства и цели). Так как данный процесс не выделен очевидно, то каждые трансформации требований клиента дополнительную оплату либо отметаются консультантами/проектировщиками как неосуществимые.

Сходу появляется конфликт, но так как процесс управления требованиями не обрисован, не выяснен в контракте либо в проектной документации, появляются коллизии и недовольство.

В качестве инструментов употребляются разные программные приложения от редактора таблиц MS Excel до MS Project и им аналогичных.

В понятии «технологичности» кроме инструмента и методики возможно разглядывать и работу с персоналом, и методы управления проектами, и т.д. Это громадная отдельная тема, и нам бы не хотелось в данной статье останавливаться на этих вопросах.

на данный момент же разглядим подробнее источники оказания и методику услуг ее разработки.

Методика консалтинга

При выборе того либо иного поставщика одолжений клиенты начинают интересоваться наличием у компании-консультанта собственной методики либо применением ей известных методик. В большинстве случаев, все консультанты при продаже одолжений утверждают, что они имеют такую методику, либо придерживаются методики ORACLE, к примеру. Но методика ORACLE предусматривает разработку для того чтобы огромного числа проектных документов, что уже по окончании заключения соглашения, ни консультант, ни клиент, не может осилить согласование и разработку для того чтобы количества документации.

Методика же ORACLE – это стройная совокупность процессов и документов. В случае если выкидывать «не необходимые», на первый взгляд, документы, начнутся сбои и коллизии, как в любой совокупности, из которой бездумно вынули часть элементов. Попытайтесь поэкспериментировать над любой живой совокупностью.

С чего нужно затевать при разработке собственной методики?

Прежде всего, нужно осознать, какой продукт компания создаёт. Значительно чаще консалтинговые компании уверены в том, что они оказывают как раз «консалтинговые» услуги. Но при ближайшем рассмотрении узнается, что кроме того при внедрении 1С эти услуги более похожи на «проектные», чем на консалтинговые.

Разумеется, что под консалтингом должно пониматься как раз консультирование при внедрении программных продуктов, а не составление технического задания (ТЗ) и внедрение совокупности в соответствии с ним. Само собой разумеется, элементы консалтинга все компании вынуждены делать на первых проектных стадиях, поскольку процессы у клиента не оптимальны по большому счету либо не оптимальны для конкретного программного инструментария. К примеру, все знают, что российские компании время от времени вынуждены делать бухгалтерские проводки «задним числом».

Но западные продукты типа Микрософт AX, SAP, ORACLE таких вольностей не разрешают: закрытые период – он и имеется закрытый. Приходится время от времени оказывать клиенту «медвежью услугу», «оптимизируя» его процессы.

Но конечным продуктом все же являются АСУ. Следовательно, результатом таковой работы будет как раз создаваемая (проектируемая, внедряемая) информационная совокупность. Сделав таковой вывод, нужно отыскать стандарты, определяющие методы разработки подобных систем. При с информационными совокупностями на данный момент главными действующими являются стандарты ISO 12207, ISO 9001:2008, CMMI и ГОСТ серии 34.

Во всех больших компаниях производителях ПО существуют личные методики разработки, как в компании ORACLE, к примеру. (лит. 8).

Во вторую очередь нужно выделить стадии (этапы) создания таковой совокупности. Эти стадии кроме этого определяются существующими стандартами. Значительно чаще это: предпроектная подготовка (продажа), обследование предприятия (определение требований), системное и техническое проектирование, опытная эксплуатация и разработка. Кое-какие компании применяют термин «дизайн проекта». К сожалению, ни в одном из перечисленных стандартов для того чтобы термина не выяснено. К тому же в «дизайн проекта» складывается все данные по проектируемой совокупности: входные/выходные отчеты, методы, формулы, процессы и т.д.

В итоге за самую долгую стадию работ клиент должен заплатить до 70% бюджета проекта, не взяв на выходе ничего. При же стандартной модели жизненного цикла, клиент может уже на первом этапе вносить трансформации в проектную документацию, новые требования, разбирать прототип совокупности.

По окончании определения жизненного цикла нужно выяснить, какие конкретно проектные документы разработчик будет воображать клиенту на согласование. И тут самый стремительный и несложный вариант – применение действующих стандартов. В лит. 3 приводится полный перечень документации, которая обязана разрабатываться при проектировании АСУ. Если консалтинговая компания занимается лишь внедрением программного приложения, большая часть документов возможно не разрабатывать.

В случае если же компания формирует АСУ «под ключ» с поставкой элементов техобеспечения, тем более имеет суть ознакомиться с содержанием и составом соответствующих документов из представленных стандартов.

Главное внимание в аналогичных проектах направляться обратить не только на правильность постановки целей проекта, но и на проведение полноценных тестов совокупности. В отсутствие четкой методики проектирования, консультанты сдают результаты работы совокупности в виде отчетов, каковые, на первый взгляд, удовлетворяют клиента. Фактически ни при каких обстоятельствах не проводятся процедуры, определенные стандартом лит.

4. Это ведет к тому, что работа совокупности в течение уже первого месяца может нарушаться, и требуются большие упрочнения по ее исправлению и доработке неточностей для восстановления работоспособности, что, само собой разумеется, выгодно консалтинговой компании, но не всегда приветствуется клиентом в силу перерасхода бюджета.

На последнем шаге остается создать процедуры обеспечения качества работ на проектах и его контроля. И тут возможно воспользоваться стандартом ISO 9001:2000.

Само собой разумеется, нужно в любом случае изучить стандарты CMMI, SPACE. Это стандарты, обрисовывающие процессы разработки ПО. Так как, в большинстве случаев, «консалтинговые» компании не считая оптимизации процессов вынуждены заниматься и донастройкой программного инструмента и, практически в любое время, дополнительным программированием (кастомизацией).

Из этих стандартов нужно забрать необходимые процессы (хотя бы уровня 3 CMM).

Как пример возможно привести процесс «управление конфигурацией», без которого ни одна уважающая себя компания не проектирует важные совокупности. Любой из нас может отыскать в памяти массу примеров из настоящих проектов, в то время, когда члены команды проектировщика компилировали различные предположения модулей, делали противоречащие друг другу настройки в различных модулях единой совокупности и т.д. На обучении я довольно часто привожу пример коммерческого директора одной из торговых сетей русского города-миллионника, которому были на протяжении проектирования совокупности выданы все права на ее настройку. Он поставил в AXAPTA галочку «распространить на всю группу товаров» и забыл про это.

Спустя семь дней он установил наценку на один из сортов колбасы 3% (заканчивались сроки реализации) в то время как средняя наценка по группе была 27%.

Убыток в 25 тысяч американских долларов внесли предложение оплатить консультантам.

Краткое описание стадий жизненного цикла

Предпроектное обследование проводится с целью подготовки контракта с логическими рамками работ. За эту стадию отвечает, в большинстве случаев, коммерческий отдел, что может завлекать консультантов. Так как все процессы в компании должны быть взаимосвязаны, хорошо, дабы в описании стадии «Предпроектное обследование», были отмечены связи с процессом продаж, а правильнее кроме того с разработкой продаж. Кроме этого как и каждая разработка, разработка продаж должна быть основана на инструментах и методике продаж (Микрософт CRM и т.п.). Из собственной практики могу заявить, что главные неприятности между процессами (подразделениями, несущими ответственность за эти процессы) появляются в вопросах определения цены одолжений. С одной стороны, продавцы приобретают бонусы за количество продаж, иначе – за сами продажи.

Значительно чаще все-таки продавцы стараются реализовать продукт/услугу дешевле, предполагая, что по ходу проекта покажется возможность расширить количество бюджета проекта, наряду с этим они делают продажу. Проектные же отделы (если они технологичны и не только создают качественный продукт, но и заинтересованы в уменьшении его себестоимости) не готовы трудиться по недорогим расценкам. Это на практике довольно часто приводит не только к срыву сделок, но и к разобщению различных отделов в компании-проектировщика.

Выход тут лишь один – формализация взаимоотношений, четко проработанные KPI для каждого отдела.

На Обследовании предприятия главная работа консультантов направлена на получение максимально подробной информации о предприятии: бизнес-процессах, подлежащих автоматизации, существующей информационной совокупности, уровне обучения пользователей, целях. Принципиально важно, что главным результатом деятельности на данной стадии есть состав функций бизнес-процессов, подлежащих автоматизации и информационные входы-выходы будущей совокупности. Кроме функций совокупности нужно выяснить цели будущей совокупности, исходя из целей бизнес-процессов (теоретический нюанс целеполагания – предмет изучения второй статьи и обрисован, к примеру, в лит.7). Принципиально важно, что по итогам работ на данной стадии клиенту представляется документ (к примеру, «Отчет об обследовании»), что он может верифицировать, но не обязательно утверждать. Суть верификации документа в том, дабы удостовериться, что консультанты (проектировщики) верно осознали бизнес клиента.

На практике данный документ не читается экспертами клиента либо читается не всеми экспертами, что приводит неизменно к кросс-не-согласованности его положений между разными подразделениями предприятия и, как следствие, к неточностям при автоматизации бизнес-процессов.

Довольно часто консультанты вынуждены оптимизировать существующие бизнес-процессы клиента, поскольку последние время от времени принципиально не алгоритмизируемы. К примеру, на предприятии, торгующем элитной мебелью, существовал отдел продаж. В этом отделе были выяснены кое-какие процессы. Но один из продавцов, осуществляющий около 70% всех продаж, категорически отказывался делать эти процессы, в частности все финансовые средства приносил «наличными» и сдавал в кассу предприятия, в то время как остальные трудились лишь по безналичным перечислениям. Само собой разумеется, наряду с этим существовали неприятности с налоговыми органами, но они как-то решались.

Автоматизировать же такое было фактически нереально (все процессы ценообразования, учета товаров и т.п. не исполнялись этим неповторимым продавцом).

При Системном проектировании строится модель (либо прототип) будущей совокупности. Нужно четко придерживаться системного подхода на данной стадии, что содержится прежде всего в построении связей системы (элементов и морфологии состава, ее связей и границ системы с внешними сущностями), а также в анализе совокупности на микро- и макро- уровне. Техническое задание, на основании которого будет строиться совокупность, есть главным проектным документом. При элементном анализе совокупности нужно предусмотреть, как элементы бизнес-процессов, обрисованных на прошлой стадии, трансформируются в элементы IT-функции и инфраструктуры автоматизированной совокупности. В большинстве случаев, никто не занимается анализом и таким синтезом бизнес-информационных систем и систем. Это приводит неизменно к дублированию функций и элементов подразделений (к примеру, ко

spacer