План внедрения: новое и забытое старое

Пищиков С. В.
project manager, "Ш.ЭЙР-С"

Вступление

В конце 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 (коэффициент эффективности инвестиций) для проектов по автоматизации вызывает значительные трудности даже в наиболее "продвинутых" странах. Цели не определяются с точки зрения чисто финансовой выгоды, а связываются с появлением новых источников информации или получением качественного экономического эффекта.

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

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

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

Продолжение - часть 2