Бизнес план по внедрению асу

В качестве предисловия.

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

Однако, справедливости ради, стоит отметить излишнюю склонность автора к использованию с трудом запоминаемой простым предпринимателем «импортную» терминологию (MRPII, ERP и т.п.), а также ссылки на западные «авторитеты». Правда, наверное это простительно современному «project manager»у.

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

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

Но, если отвлечься от теории, то вам предлагается очень полезная статья, написанная языком доступным для понимания большинству современных руководителей. Даже получивших «образование» уже во времена всеобщей ЕГЭизации населения.

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

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

Вступление

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

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

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

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

План Уайта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример из жизни:

— Петрович (зав. складом), отпусти «Кентавру» (покупатель). Я накладную попозже занесу, не хочу клиента заставлять ждать: берут много, платят налом.

— Нельзя.

— Да ты что? Всегда же так делали.

— А теперь шеф штрафует. Все — через компьютер.

— Во программеры Дармоеды очкастые. Работать не дают. Разогнать бы!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Причины:

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

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

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

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

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

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

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

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

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

Источник — consulting.ru