Токарев Михаил Валентинович : другие произведения.

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

Самиздат: [Регистрация] [Найти] [Рейтинги] [Обсуждения] [Новинки] [Обзоры] [Помощь|Техвопросы]
Ссылки:


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


ТЕХНОЛОГИЯ КОНСАЛТИНГА

  
   В России с начала века начался резкий рост IT-рынка вообще и консалтинговых услуг в этой сфере в частности. Все больше и больше консалтинговых компаний входит в рынок консалтинговых услуг, предлагая свое видение и инструментов (программного обеспечения), и технологий производства услуг. Но до "перегретости" рынка еще далеко, так как спрос значительно опережает предложение.
   На фоне растущих объемов услуг сам предмет приложения усилия этих компаний остается недостаточно стандартизованным, а большинство компаний и вовсе не придают значения подобным "мелочам".
   Многие консультанты считают, что достаточно изучить инструментальное обеспечение и предприятия-клиенты выложат любые деньги за их услуги.
   Цель данной статьи - предложить выходы из этой ситуации, помочь консалтинговым компаниям сделать проектные работы более технологичными.
  
   О терминологии
   Понятийный аппарат современных консалтинговых услуг настолько размыт, что нет смысла спорить с авторами, по-разному трактующими термины MRP, ERP и т.п.
   В контексте данной статьи мы будем использовать термины представленные ниже.
   АСУ - целостная организационно-техническая совокупность элементов (информационной инфраструктуры, персонала и регламента) обеспечивающих выполнение автоматизированных информационных процессов, связанных общей функциональностью, информационными потоками и целевым назначением. Это термин, определенный в Лит. 1 и не имеет смысла никак по-другому определять эти системы. В иностранных стандартах этот термин определяется как "информационные системы" (ISO 12207). Мы не приемлем термина КИС, просто потому что не существует такого стандартизованного термина и информационные системы внедряются не только в "Корпорациях".
   Инфраструктура - взаимосвязанная совокупность средств технического, программного и информационного обеспечения, представленная в виде иерархической послойной структуры объектов, обеспечивающих выполнение всех установленных функций АСУ. В Инфраструктуру входят следующие совокупности элементов по слоям: прикладной (приложения), информационный (БД, СУБД), вычислительный (сервера, рабочие станции и т.п.), транспортный (сетевое оборудование, оборудование передачи информации и т.п.), физический (кабельные системы, системы бесперебойного питания, кондиционирования и т.п.).
   Система - совокупность сильносвязанных элементов, обладающая минимум 4 свойствами:
  -- Целостность - это целостная совокупность целостных элементов;
  -- Связи - существенные и устойчивые связи элементов друг с другом превосходят по силе связи этих элементов с другими элементами, не входящими в данную систему;
  -- Организация - энтропия системы меньше суммы энтропий входящих в нее элементов;
  -- Интегративные качества - у системы есть такие качества, которые не присущи ни одному из ее элементов в отдельности (Лит. 7).
   Составляющие технологии
   Любая технология включает в себя методику производства работ и инструменты, обеспечивающие это производство.
   Для консалтинговых компаний методикой является совокупность документов, описывающих:
  -- жизненный цикл работ, начиная от предпродажной подготовки и заканчивая сопровождением создаваемых систем;
  -- процедуры обеспечения качества работ;
  -- процедуры управления проектами;
  -- документацию, которая предоставляется клиентам в ходе работ.
   В качестве инструментов используются различные программные приложения от редактора таблиц MS Excel, до MS Project и им подобных.
   В понятии "технологичности" помимо методики и инструмента можно рассматривать и работу с персоналом, и способы управления проектами, и т.д. Это большая отдельная тема и нам бы не хотелось в этой статье останавливаться на этих вопросах.
   Сейчас же рассмотрим подробнее методику оказания услуг и источники ее разработки.
  
   Методика консалтинга
   При выборе того или иного поставщика услуг заказчики уже давно интересуются наличием у фирмы-консультанта собственной методики или использованием ей известных методик.
   С чего надо начинать при разработке собственной методики?
   В первую очередь, надо понять какой продукт компания производит. Чаще всего консалтинговые компании считают, что они оказывают именно "консалтинговые" услуги. Однако при ближайшем рассмотрении выясняется, что даже при внедрении 1С эти услуги более "проектные", чем консалтинговые. Очевидно, что под консалтингом должно пониматься именно консультирование при внедрении программных продуктов, а не составление Технического Задания (ТЗ) и внедрение системы в соответствии с ним.
   Таким образом, большинство компаний выполняет все-таки проектные работы. Следовательно, результат такой работы будет именно создаваемая (проектируемая, внедряемая) информационная система. Сделав такой вывод, необходимо найти стандарты, определяющие способы разработки подобных систем. В случае с информационными системами, в настоящее время действующими являются стандарты ISO 12207, ISO 9001:2000 и ГОСТ серии 34. Во всех крупных компаниях производителях программного обеспечения существуют собственные методики разработки, как в компании ORACLE, например, Лит. 8.
   Часто, помимо внедрения системы, консультанты занимаются и чисто "консалтинговым" бизнесом. Например, заказчику предлагается оптимизация бизнес-процессов, постановка управленческого учета, аудит бухгалтерский и не только. Именно здесь и надо четко определить предмет оказания услуг.
   Во вторую очередь надо определить стадии (этапы) создания такой системы. Эти стадии определяются существующими стандартами. Чаще всего это: предпроектная подготовка (продажа), обследование предприятия, системное и техническое проектирование, разработка и опытная эксплуатация.
   Затем надо определить какие проектные документы разработчик будет представлять клиенту на согласование. И здесь самый быстрый и простой вариант - использование действующих стандартов. В Лит. 3 приводится полный список документации, которая должна разрабатываться при проектировании АСУ. В случае если консалтинговая компания занимается только внедрением программного приложения, большинство документов можно не разрабатывать. Если же компания создает АСУ "под ключ" с поставкой элементов технического обеспечения, тем более имеет смысл ознакомиться с составом и содержанием соответствующих документов из представленных стандартов.
   Основное внимание в подобных проектах следует обратить не только на правильность постановки целей проекта, но и на проведение полноценных тестов системы. В отсутствие четкой методики проектирования, консультанты сдают результаты работы системы в виде отчетов, которые на первый взгляд удовлетворяют клиента. Практически никогда не проводятся процедуры, определенные стандартом Лит. 4. Это приводит к тому, что работа системы в течение уже первого месяца может нарушаться, и требуются значительные усилия по ее доработке и исправлению ошибок для восстановления работоспособности.
   На последнем шаге остается разработать процедуры обеспечения качества работ на проектах и его контроля. И здесь можно воспользоваться стандартом ISO 9001:2000.
  
   Краткое описание стадий жизненного цикла
   Предпроектное обследование проводится с целью подготовки договора с логическими рамками работ. За эту стадию отвечает, как правило, коммерческий отдел, который может привлекать консультантов.
   На Обследовании предприятия основная работа консультантов направлена на получение как можно более подробной информации о предприятии: бизнес-процессах, подлежащих автоматизации, существующей информационной системе. Важно, что основным результатом деятельности на этой стадии является состав функций бизнес-процессов, подлежащих автоматизации и информационные входы-выходы будущей системы. Помимо функций системы необходимо определить цели будущей системы, исходя из целей бизнес-процессов (теоретический аспект целеполагания описан, например, в Лит. 7).
   При Системном проектировании строится модель будущей системы. Необходимо четко придерживаться системного подхода на данной стадии, который заключается в первую очередь в построении морфологии системы (состава и связей элементов, границ системы и ее связей с внешними сущностями). Техническое задание, на основании которого будет строиться система, является основным проектным документом. Часто консультантами разрабатывается документ под названием "Дизайн решения". Этот термин перекочевал из западных методик проектирования. Не будем здесь приводить аргументы за ту или иную методику или документацию - все они применимы, если используют существующие стандарты.
   При Техническом проектировании и Разработке проводится детализация требований к системе, спроектированных в Техническом задании и программирование тех функций, которые отсутствуют в стандартной поставке программного обеспечения.
   Опытная эксплуатация описана достаточно подробно и понятно в Лит. 10.
   В крупных консалтинговых компаниях создаются отделы технической поддержки клиентов для организации работ по Сопровождению системы. Четко налаженная работа таких отделов позволяет получать дополнительный доход от клиентов, у которых система уже успешно функционирует.
  
   Инструмент консалтинга
   Мы уже упоминали программные приложения, чаще всего используемыми при управлении проектами. Это и MS Excel, и MS Project, и другие системы подобного назначения.
   Однако для клиента очень важно то, что компания-исполнитель не только предлагает к внедрению системы на платформе поставляемых программных продуктов, но и сама использует их в своей работе. Если консалтинговая компания внедряет ERP-системы, неплохо бы, чтобы в качестве одного из инструментов управления проектами использовалась аналогичная система.
   Итак, какова же роль технологии в консалтинге?
   Во-первых, она позволяет улучшить качество работы за счет стандартизации процессов. Во-вторых, она позволяет быстрее обучать новый персонал. В третьих, она позволяет снижать проектные риски, о которых говорится в следующем разделе.
  
   Проектные риски
   Риски, возникающие на проектах внедрения ERP-систем (АСУ) всем известны, это:
  -- недостаточный бюджет проекта;
  -- недостаточный опыт консультантов;
  -- недостаточная заинтересованность ключевых специалистов заказчика в результатах проекта;
  -- нечеткое понимание целей проекта, как со стороны Заказчика, так и со стороны консультантов, изменение целей по ходу проекта;
  -- смена ключевых людей по ходу проекта;
  -- недостаточная готовность заказчика к изменениям бизнес-процессов в соответствии с теми способами автоматизации их функций, которые предложены в системе, а иногда и принципиальное нежелание (что приводит к увеличению себестоимости проекта и к появлению дополнительных ошибок реализации);
  -- задержка заказчиком сроков согласования проектной документации.
   Использование технологии проектирования позволяет снизить большинство перечисленных рисков и даже исключить некоторые из них.
   Проекты по внедрению ERP-систем обходятся заказчику от 100 000 до нескольких миллионов долларов. Не успешность проекта может привести не только к лишним затратам, но и сбоям в бизнесе заказчика, если на новую систему возлагаются критичные функции.
  
  
  
   Использованная литература
  
   Лит. 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 "Виды испытаний автоматизированных систем".

 Ваша оценка:

Связаться с программистом сайта.

Новые книги авторов СИ, вышедшие из печати:
О.Болдырева "Крадуш. Чужие души" М.Николаев "Вторжение на Землю"

Как попасть в этoт список
Сайт - "Художники" .. || .. Доска об'явлений "Книги"