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

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

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

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

Цель данной статьи – предложить выходы из этой ситуации, помочь консалтинговым компаниям сделать проектные работы более технологичными. Для представления технологии, понятной большинству ее пользователей, необходимо сначала определить понятийный аппарат. И здесь очевидно необходимо использовать исключительно стандартизованные термины. Ведь никто не строит здания без ГОСТ и СНИП. АСУ не менее сложные системы, чем здания, но считается, что они не настолько опасны для жизни, а значит, возможно забыть про стандарты.

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

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

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

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

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

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

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

Составляющие технологии

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

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

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

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

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

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

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

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

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

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

В первую очередь, надо понять, какой продукт компания производит. Чаще всего консалтинговые компании считают, что они оказывают именно «консалтинговые» услуги. Однако при ближайшем рассмотрении выясняется, что даже при внедрении 1С эти услуги более похожи на «проектные», чем на консалтинговые. Очевидно, что под консалтингом должно пониматься именно консультирование при внедрении программных продуктов, а не составление технического задания (ТЗ) и внедрение системы в соответствии с ним. Конечно, элементы консалтинга все компании вынуждены делать на первых проектных стадиях, так как процессы у клиента не оптимальны вообще или не оптимальны для конкретного программного инструментария. Например, все понимают, что российские компании иногда вынуждены делать бухгалтерские проводки «задним числом». Однако западные продукты типа Microsoft 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 тысяч американских долларов предложили оплатить консультантам.

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

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

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

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

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

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

При Техническом проектировании и Разработке проводится детализация требований к системе, спроектированных в техническом задании и программирование тех функций, которые отсутствуют в стандартной поставке программного обеспечения.

Опытная эксплуатация описана достаточно подробно и понятно в Лит. 10.

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

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

Обеспечивающие процессы

Так как процессный подход был придуман относительно недавно, прямое использование советских стандартов (действующих на данное время) затруднительно. Однако тут как раз помогают иностранные стандарты, которые считаются действующими для России, если не существует стандарта локализованного. Такими стандартами являются, например CMMI.

В локализованном стандарте ISO9001:2008 процессный подход уже применяется, что значительно упрощает создание собственных методик проектирования.

Итак, какие же процессы должны быть отражены обязательно в методике проектирования?

Стандарты определяют всю их совокупность:

• документирование;
• управление;
• обеспечение качества;
• управление конфигурацией;
• управление требованиями;
• верификация и валидация;
• управление несоответствующей продукцией;
• управление рисками;
• управление закупками.

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

• владельца процесса;
• связь с другими процессами;
• совокупность подпроцессов, функций;
• входные/выходные потоки;
• цели процесса.

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

Инструмент консалтинга

Мы уже упоминали программные приложения, чаще всего используемые при управлении проектами. Это и MS Excel, Word, MS Project и другие системы подобного назначения.

Однако для клиента очень важно то, что компания-исполнитель не только предлагает к внедрению системы на платформе поставляемых программных продуктов, но и сама использует их в своей работе. Если консалтинговая компания внедряет ERP-системы, неплохо бы, чтобы в качестве одного из инструментов управления проектами использовалась аналогичная система.

Итак, какова же роль технологии в консалтинге?

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

Проектные риски

Риски, возникающие на проектах внедрения ERP-систем (АСУ), всем известны, это:

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

Использование технологии проектирования позволяет снизить большинство перечисленных рисков и даже исключить некоторые из них.

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

Использованная литература

1. РД 50-680-88 «Автоматизированные системы: Основные положения».

2. ГОСТ 34.601-90 «Автоматизированные системы: Стадии создания».

3. ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

4. РД 50-34.698-90 «Автоматизированные системы: Требования к содержанию документов»

5. Г.Н. Калянов «Консалтинг при автоматизации предприятий».

6. ГОСТ 34.602-89 «Информационная технология: Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

7. В.И.Николаев, В.М.Брук «Системотехника: методы и приложения».

8. Oracle Method. Application Implementation Method (AIM) 3.0 Handbook.

9. Oracle Method. Application Implementation Process and Task Reference.

10. ГОСТ 34.603-92 «Виды испытаний автоматизированных систем».

Источник изображения: pixabay.com