Особенности внедрения

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

Этап, №	Содержание этапа работ
1	Встречи с руководителями предприятия. Обоснование проекта внедрения
2	Создание команды внедрения на предприятии
3	Предпроектная подготовка. Создание и защита бизнес-плана
4	Описание бизнес-процессов
5	Построение и утверждение модели будущей автоматизированной системы управления предприятием
6	Написание и утверждение технического задания на разработку системы
7	Разработка системы
8	Обучение сотрудников предприятия
9	Заведение нормативно-справочной информации
10	Опытное внедрение
	ИТОГО

Примечания: Реальные сроки внедрения на конкретном предприятии зависят от:

• выбранной автоматизированной системы;

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

• готовности руководства и сотрудников предприятия к внедрению;

• численности конечных пользователей;

• объема нормативно-справочной информации;

• других параметров проекта.

Вступление

В конце 70-х годов в Америке появился новый (по тем временам) прогрессивный стандарт MRP. Его возникновение и массовое использование стало ответом на хлынувший в Штаты поток дешевых японских автомобилей и угрозу знаменитому американскому автомобилестроению. Внедрение новой концепции позволило значительно повысить эффективность производства и уменьшить себестоимость выпускаемой продукции.

Практическая реализация стандарта невозможна без внедрения комплексной системы автоматизации. Один из разработчиков MRP Оливер Уайт предложил и стал широко применять подробный план внедрения программ комплексного управления предприятием (MRP-программ).

Этот план был проверен опытом тысяч компаний в течение 20 с лишним лет. Он широко использовался для внедрения MRPII, ERP и других технологий, так что сам стал фактически стандартом. В дальнейшем мы будем называть его планом Уайта.

Рассмотрим план Уайта подробнее, сравним его с российским ГОСТом и планами внедрения некоторых известных ИТ-компаний (Scala, Галактика, ЭпикРус и др.). Проанализируем приемы внедрения ПО, разработанного методом "экстремального программирования".

План Уайта

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

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

Нулевой цикл включает:

• предварительное обследование и оценку состояния (предпроектное обследование);

• предварительную переподготовку;

• техническое задание;

• технико-экономическое обоснование;

• организацию проекта;

• выработку целей.

Рассмотрим каждый этап подробнее.

Предпроектное обследование

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

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

• № и наименование процесса;

• № и наименование процесса верхнего уровня;

• №№ и наименования вложенных детальных процессов следующего уровня;

• текстовое описание процесса;

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

• события, инициирующие процесс;

• события, завершающие процесс;

• перечень функций процесса;

• перечень функций, контролирующих выполнение процесса;

• перечень входящих документов;

• перечень входящих материальных ресурсов;

• перечень исходящих документов;

• перечень исходящих материальных ресурсов;

• перечень подразделений и должностей, участвующих в процессе;

• типы используемых систем автоматизации.

На основе исследований строятся модели "as is" (как есть) и "to be" (как должно быть). Реорганизация представляет собой переход от одной модели к другой и позволяет навести элементарный порядок в организации процессов.

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

• схема бизнес-процессов "as is";

• схема бизнес-процессов "to be";

• бизнес-план реорганизации;

• краткосрочный план действий.

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

Предварительная переподготовка

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

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

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

Действовать предлагается не "по понятиям", а по правилам. Для носителей российского менталитета это всегда тяжелое испытание ("Что я, сам не знаю, как лучше делать?").

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

Есть ряд других проблем, но на них мы не будем сейчас останавливаться.

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

Техническое задание

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

• требования к автоматизированным рабочим местам, их составу и структуре;

• разработка требований к программным средствам;

• разработка топологии, состава и структуры локальной вычислительной сети;

• требования к секретности и защите информации.

Процессы системы делятся на:

• ручные (регламентируются, но не автоматизируются);

• пакетные (как правило, сбор статистических данных, получение отчетности за период, пересчеты глобальных регистров);

• диалоговые (подавляющее большинство процессов в современных АСУП);

• процессы реального времени.

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

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

Формально составление технического задания — работа заказчика, однако в большинстве случаев этим занимается фирма, проводящая внедрение.

Технико-экономическое обоснование

Анализ "затраты-эффект" позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.

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

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

Менее благополучно дело обстоит с внедрением бухгалтерских модулей.

Какую экономическую выгоду получит предприятие, если заменит "плохую" бухгалтерскую систему на "хорошую"? Например, повышение качества учета. Адекватная бухгалтерская система "организует" работающего в ней бухгалтера.

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

Установка на таком предприятии хотя бы "1С" ведет к уничтожению существующей бухгалтерской "матрицы" и вносит некоторый учетный порядок. Однако единственный аргумент в пользу внедрения — необходимость полностью перестраивать учет в случае ухода "концептуального главбуха".

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

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

• уменьшается вероятности ошибки (особенно если расчеты многовалютные);

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

• существует возможность в режиме реального времени отслеживать должников и своевременно принимать меры.

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

Многие так называемые "точные данные" приводятся ИТ-компаниями в основном для психологического эффекта. Общие слова и цифры, результаты статистики вряд ли могут произвести на руководство заказчика сильное впечатление.

Организация проекта

Существуют три уровня организации проекта (для больших предприятий):

• Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.

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

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

Важнейшая цель организации проекта — вовлечение сотрудников компании-клиента в процесс внедрения. Это достигается через распределение ответственности. Персонал отвечает за автоматизацию своих участков.

Оптимальная структура рабочей команды:

• сотрудник (сотрудники) заказчика, работающие на данном участке. Задачи: консультировать ИТ специалистов, осуществлять текущий контроль и предварительную приемку внедряемых объектов (формы, документы, отчеты и т. д.);

• сотрудник (сотрудники) отдела информационных технологий (ОИТ) заказчика. Задачи: освоить в необходимом объеме инструментальные средства исполнителя ("1С", "Галактика", Scala, R3 и др.), участвовать в доводке и разработке автоматизированной системы, служить информационным "буфером" между сотрудниками клиента и консультантами исполнителя;

• консультанты-программисты исполнителя. Задачи: разработать, внедрить, адаптировать необходимые модули, консультировать сотрудников ОИТ заказчика.

Использование в разработке и внедрении сотрудников ОИТ компании-клиента — не просто важный, а необходимый шаг. От него во многом зависит успех автоматизации.

Причины:

• сотрудники ОИТ так или иначе уже проводили автоматизацию своего предприятия и обладают ценным "know-how", которым на уровне диалога делиться, скорее всего, не станут;

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

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

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

Выработка целей

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

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

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

Данные, как товар, не должны просто лежать где-то в компании. Их надо довести до конечных пользователей, причем желательно — пока данные свежие.

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