Статьи

Версия для печати

Все статьи | Статьи за 2003 год | Статьи из номера N2 / 2003

Корпоративные информационные системы: не повторяйте пройденных ошибок

Верников Г.Г.,

консультант и эксперт
в области корпоративного управления.
Основатель и управляющий партнер
консалтинговой компании «Верников и партнеры»

«Уточните значение слов, и вы избавите
человечество от большей части его заблуждений».
Рене Декарт

Что такое информационная система?

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

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

Бизнес-модель — это описание предприятия каксложной системы с заданной точностью. В рамках бизнес-модели отображаются всеобъекты (сущности), процессы, правила выполнения операций, существующаястратегия развития, а также критерии оценки эффективности функционирования системы. Форма представлениябизнес-модели и уровень ее детализации определяются целями моделирования ипринятой точкой зрения.  

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

Информационная система (ИС) — это всяинфраструктура предприятия, задействованная в процессе управления всемиинформационно-документальными потоками, включающая в себя следующиеобязательные элементы:

  • Информационную модель, представляющая собой совокупность правил и алгоритмов функционирования ИС. Информационная модель включает в себя все формы документов, структуру справочников и данных и т.д.
  • Регламент развития информационной модели и правила внесения в нее изменений.
  • Кадровые ресурсы (департамент развития, привлекаемые консультанты), отвечающие за формирование и развитие информационной модели.
  • Программный комплекс (ПК), конфигурация которого соответствует требованиям информационной модели (программный комплекс является основным движителем и одновременно  механизмом управления ИС). Кроме этого всегда существуют требования к поставщику ПК, регламентирующие процедуру технической и пользовательской поддержки на протяжении всего жизненного цикла.
  • Кадровые ресурсы, отвечающие за конфигурирование ПК  и его соответствие утвержденной информационной модели.
  • Регламент внесения изменений в конфигурацию ПК и состав его функциональных модулей.
  • Аппаратно-техническую базу, соответствующая требованиям по эксплуатации ПК (компьютеры на рабочих местах, периферия, каналы телекоммуникаций, системное ПО и СУБД).
  • Эксплуатационно-технические кадровые ресурсы, включая персонал по обслуживанию аппаратно-технической базы.
  • Правила использования ПК и пользовательские инструкции, регламент обучения и сертификации пользователей. 

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

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

Вас назначили заместителем главы городской администрации ипоставили приоритетную задачу — наладить систему общественного транспорта.Перед вами встает следующий перечень проблем:

  1. Определение целей функционирования транспортной системы и основных ее параметров. Для чего проводится проект? Исходя из какой системы критериев будут оцениваться результаты?
  2. Разработка требований по экономической эффективности, планирование политики ценообразования. Какова должна быть стоимость билетов и все прочие расходы, чтобы была возможность поддерживать и развивать инфраструктуру?
  3. Реконструкция существующих дорог и/или строительство новых, соединяющих основные городские объекты. С каким покрытием целесообразно строить дороги, чтобы, с одной стороны, укладываться в узкие рамки бюджета, а с другой — позволять использовать современные автобусы?
  4. Определение маршрутов, остановок и режима работы транспорта на линиях. Как не допустить негативного проявления консерватизма пассажиров при изменении (отмене) имеющихся маршрутов в результате проекта?
  5. Какие автобусы следует приобретать: отечественные или импортные? Какой марке отдать предпочтение? Каков должен быть баланс между большими автобусами и «маршрутками»? На каких маршрутах приоритетна пассажиро-вместимость, а на каких скорость доставки?
  6. Что делать со старым парком автобусов? Продолжать использовать в новых условиях или списывать?

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

Каждой проблеме из вышеизложенного перечня можносопоставить похожий вариант, но относящийся к проблематике внедрения ИС.Перечислим их в том же порядке.

  1. Для решения каких управленческих (производственных) задач нам нужна ИС? Как мы будем определять, справляется ли она с возложенными на нее функциями?
  2. Как мы будем оценивать экономическую эффективность от внедрения? Сопоставима ли реальная экономическая отдача полной стоимости владения?

    Примечание: Справедливости ради, должен сказать, что до сих пор не встречал ни одного универсального математического подхода к оценке экономической эффективности проектов внедрения ИС. Основная проблема оценки заключается в том, что ИС не способна напрямую повлиять на финансово-экономические показатели, а может лишь вовремя предоставлять нужную информацию руководителям и тем самым обеспечивать высокое качество управленческих решений. А верные и актуальные решения, в свою очередь, являются основой любого экономического подъема и увеличения конкурентоспособности.

    Для того чтобы прочувствовать сложность задачи на жизненном примере, достаточно попытаться оценить, насколько отличается в одних и тех же условиях средняя скорость движения исправного автомобиля из пункта А в пункт Б по сравнению с таким же по характеристикам автомобилем, но с неисправной приборной панелью и без зеркал заднего вида?

    В настоящий момент существуют три использующихся подхода к оценке эффективности инвестиций в реализацию ИС: бенчмаркинг (постфактум анализа результатов похожих проектов), экспертная оценка и применение метода сбалансированной оценочной ведомости (The Balanced Scorecard). Последний был разработан в 1990 г. Дэвидом Нортоном и Питером Капланом и представляет собой современную методику анализа состояния компании, базирующуюся на нефинансовых показателях. Эта методика позволяет рассматривать ИС как элемент компании, представляющий собой одно из главных стратегических преимуществ с точки зрения технологичности бизнеса, и оценивать итоговые экономические показатели в результате экспертного анализа качественных улучшений бизнес-процессов на всех уровнях управленческой иерархии. Однако очевидно, что точного преобразования из качества в количество добиться невозможно, поэтому и этот подход страдает определенным субъективизмом. Тем не менее его применение, особенно с привлечением нескольких экспертов, является целесообразным.

  3. Какие новые бизнес-процессы необходимо внедрить, а какие реорганизовать, для того чтобы отдача от использования ИС была максимальной?
  4. По каким правилам будет осуществляться управление информационными потоками в новом режиме? Не будет ли проявляться пресловутое сопротивление персонала нововведениям?
  5. Какой программный комплекс приобретать: отечественный или зарубежный? Стоит ли инвестировать средства в многофункциональное и дорогостоящее решение или пока можно обойтись компромиссным вариантом?
  6. Что делать со старыми программами обработки информации и управления БД: интегрировать с приобретаемым решением или уничтожать?

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

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

«Может ли ваша система автоматически управлять финансами?»
Из подслушанного на выставке...

Выбор ПК, или о том, как правильно читать маркетинговые материалы

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

  • Сложность не только внутренних механизмов работы, но и наблюдаемой функциональной структуры.
  • Большой набор специфических инструментов для различных областей менеджмента. Например, многие производственные и технологические тонкости неизвестны финансовому директору, и наоборот, главный инженер некомпетентен в принципах анализа финансовых отклонений. Специалист, принимающий решение по выбору программного комплекса, как правило, является IT-менеджером и имеет лишь общее и неполное представление об использующихся управленческих методиках.
  • Наличие специальной терминологии, большого количества стандартов и псевдостандартов информационного менеджмента (очень часто общие концепции называют стандартами или вообще ориентируются на «стандарты», являющиеся частью маркетинговой политики некоторых разработчиков).
  • Доступность материалов исключительно рекламного характера, фактическое отсутствие описания реального опыта использования программного комплекса и истинной статистики внедрений.

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

  • «Наша система отвечает требованиям ERP-стандарта (класса)».

Программное обеспечение содержит функциональность, которая позволяет его использовать для построения комплексных информационных систем, включающих поддержку большинства направлений бизнеса (как минимум, управление финансами, управление производством и запасами и управление обслуживанием клиентов). Сразу необходимо уточнить, что  ERP-стандарт (Enterprise Resource Planning) попросту не существует, и он относится к  маркетинговым понятиям.

  • «Наша система отвечает требованиям стандарта MRPII».

    В отличие от ERP MRPII в некотором смысле является стандартом. Если выражаться точно, то MRPII (Manufactory Resource Planning) — это концепция управления производством и запасами,  последняя ее редакция (MRPII Standard System)  была опубликована в 1989 г. американской Ассоциацией управления производственными ресурсами APICS (http://www.apics.org).   Следует отметить, что концепция MRPII является методологией менеджмента, а не софтверным понятием, несмотря на то, что возможность ее применения на крупных предприятиях стала реальностью с прогрессом в области информационных технологий.

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

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

  • «Наша система является системой управления, а не системой учета».

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

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

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

  • «Наша система имеет многолетний опыт успешных внедрений на Западе и обладает самым большим набором отраслевых решений».

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

    Несомненно, комплексные зарубежные решения применимы и у нас. Более того, при правильном подходе их использование будет не менее продуктивным, чем на Западе. Однако для того чтобы их внедрение было успешным, всегда необходимо осуществлять реорганизацию бизнес-процессов, разрабатывать и утверждать регламент всех процедур и алгоритмов. Известно, что такой подход не является дешевым, однако ошибочно в целях экономии избегать его и вкладывать миллионы долларов в неэффективную информационную систему, пытаясь настроить подсистему производственного планирования в тех случаях, когда сама процедура планирования на предприятии не регламентирована и де-факто не существует.

  • «Наша система разработана в России и наиболее всего подходит для автоматизации отечественных предприятий».

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

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


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

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

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

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

«Дело должно соответствовать возможностям,
действия должны соответствовать времени».
Лао Цзы

Управление проектом построения информационной системы

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

  • 1992—1994 гг. Большинству руководителей стало ясно, что за компьютерами будущее и в покупку  персональных ЭВМ вкладывались довольно крупные инвестиции. Документы стали выглядеть элегантней, так как набирались в пиратских программах и распечатывались на принтерах. В определенный момент стало понятно, что поменялась только видимость работы, без какого-либо повышения эффективности бизнес-процессов. Но так как даже рынок функциональных продуктов тогда еще не достиг своей зрелости и конкуренции практически не существовало, то сама по себе оптимизация операционного цикла предприятий не представляла собой приоритетной задачи. 
  • 1994—1996 гг. Найден очевидный способ применения компьютеров: для того чтобы они смогли обслуживать бизнес-процессы (документооборот), отдельные операции которых выполняются на разных рабочих местах, нужно объединить компьютеры в единую сеть. Принимается решение о начале проекта системной интеграции. Компьютеры, которые были приобретены, к этому времени уже существенно устарели и требуют замены (модернизации). В результате проекта построена современная сеть на N рабочих мест, отвечающая всем международным стандартам. Через некоторое время, когда сглаживаются первые впечатления, приходит осознание того, что опять никаких существенных улучшений с управленческой точки зрения не произошло. Персонал приобщается к радостям Интернета (в том числе и в рабочее время), служебные записки и отчеты пересылаются в электронном виде, но в то же время все организационные проблемы продолжают негативно сказываться на темпе развития предприятия и на общей эффективности бизнеса.
  • 1996—2001 гг. Время активного интереса к корпоративным информационным системам. На рынке появляются программные продукты отечественных и западных разработчиков. Отечественные привлекают низкой ценой и близостью (территориальной и языковой) разработчика, а зарубежные высокой репутацией поставщика, большим опытом внедрений, огромной функциональностью и целым набором «готовых» отраслевых решений. При этом благодаря грамотно построенной рекламной политике у многих создается иллюзорное впечатление, что они действительно могут приобрести не пакет программного обеспечения, а  готовую систему управления, уже включающую в себя все необходимые правила и инструменты для ведения бизнеса.  Результатом подобных иллюзий явилось огромное количество как проваленных проектов, так и внедренных программных продуктов, которые, несмотря на то, что функционируют на рабочих местах, нисколько не решают злободневных производственных и управленческих задач. Не напоминает ли это вам упоминавшуюся ранее компьютерную сеть, которая существует только ради факта своего существования? Определение информационной системы приводилось в первом разделе, и, исходя из него, очевидна разница между понятиями «управленческий программный комплекс» и «управленческая информационная система».
  • Что  будет следующим шагом? Скорее всего, в ближайшем будущем обретут гладкую маркетинговую форму и будут выдвинуты предложения и о поставке комплексного продукта, включающего в себя как управленческие технологии, так и информационный инструментарий для их поддержки. Однако в любом случае подобные решения нельзя оценивать в отрыве от конкретного предприятия, стратегии его развития и существующей системы менеджмента. 

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

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

Итак, перечислим основныестадии проекта.

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


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

    • Подготовка персонала компании к проекту изменений, разработка новой политики мотивации труда.


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

    • Утверждение проектной методологии.


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

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

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


    Очень часто случается, что этим этапом пренебрегают, и в результате автоматизация не дает никаких ощутимых результатов. Внедрение ИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности ПК, уже имеют свой утвержденный регламент. Другими словами, нет никакого смысла покупать программный модуль «Бюджетирование» и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации. Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии ИС требуемой полноты и актуальности информации добиться невозможно.

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

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

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

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


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

    • Управление конфигурацией ПК согласно требованиям бизнес-модели.


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

    • Управление тестированием (стабилизацией).


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

    • Управление рисками и качеством внедрения.


    Риск всегда является неотъемлемой составляющей любого сложного и ответственного процесса. Более того, совершение рискованных действий необходимо для прогресса, а ошибки, как известно, являются основой приобретения опыта. Несмотря на то, что некоторые риски неизбежны, это не означает, что попытки определить их и управлять ими вредят творческой работе. Более подробно мы остановимся на процедуре управления рисками в следующей статье, а сейчас лишь отметим, что процедурное управление рисками на всем протяжении проекта является одним из самых главных факторов успеха.

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

    • Запуск ИС (версии) в опытную эксплуатацию.
    • Разработка правил работы с ИС и утверждение процедуры внесения изменений в конфигурацию.
    • Обучение и сертификация пользователей и администраторов.
    • Организация работы подразделения технической и пользовательской поддержки.

Отметим дополнительно, что процесс управления проектомразвития ИС является бесконечным: его динамика определяется темпом изменениявсех составляющих системы, и в первую очередь развитием бизнеса предприятия.

Отдельные номера журналов Вы можете купить на сайте www.5B.ru
Оформление подписки на журнал: http://dis.ru/e-store/subscription/



Все права принадлежат Издательству «Финпресс» Полное или частичное воспроизведение или размножение каким-либо способом материалов допускается только с письменного разрешения Издательства «Финпресс».