внимание!     некоторые материалы сайта не рекомендуются для просмотра лицам моложе 15 лет, выпускникам MBA и людям с нарушениями психики.     уходите!
 
В качестве предисловия.
Перед Вами одна из немногих (к сожалению) работ, достаточно подробно и в тоже время системно и популярно описывающих процесс внедрения автоматизированной системы управления предприятием. Отмечая попутно, как положительные факторы данного процесса, так и возникающие сложности.
Однако, справедливости ради, стоит отметить излишнюю склонность автора к использованию с трудом запоминаемой простым предпринимателем "импортную" терминологию (MRPII, ERP и т.п.), а также ссылки на западные "авторитеты". Правда, наверное это простительно современному "project manager"у.
Когда в "конце 70-х годов в Америке появился новый (по тем временам)" и далее по тексту, в Советском Союзе его давно и с успехом применяли при автоматизации социалистических предприятий и более того в обязательном порядке преподавали в профильных институтах по специальности Автоматизированные Системы Управления (например МИИТ, ф-т АВТ, с-ть АСУ).
АСУ - так тогда именовалось все то, на что сейчас навешивают иностранные этикетки. Кстати, тогда очень четко различались АСУП(предприятием) и АСУТП - технологическим процессом (что более правильно, чем бизнес процесс, на самом деле)
Кому принадлежит пальма первенства в области автоматизации предприятий, сейчас сказать трудно, однако широко известен тот факт, что американцы очень внимательно и подробно изучали социалистическую систему управления вообще и методы управления предприятиями в частности. Кстати, очень многие наработки именно советских времен легко прослеживаются практически во всех современных западных стандартах и системах "ERP".
Но, если отвлечься от теории, то вам предлагается очень полезная статья, написанная языком доступным для понимания большинству современных руководителей. Даже получивших "образование" уже во времена всеобщей ЕГЭизации населения.

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

Пищиков С. В.
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



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



    выход на главную
    на главную
    Рейтинг@Mail.ru