Как успешно выполнять проекты комплексной автоматизации.

Общие проблемы автоматизации предприятий

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

1. Это бизнес-проект, а не ИТ-проект. Автоматизация потребует не только применения какого-то специфичного программного продукта, но и многих организационных шагов.
2. Приближение к желаемому результату, скорее всего, будет многоэтапным, а возможно, и итерационным.
   Пример. На первом этапе вы, например, организуете только централизованный процесс подачи заявок на закупку, а на втором этапе привязываете заявки на закупку к лимитам платежей и получаете централизованное казначейство с контролем денежного потока. Потом вы можете опять вернуться к заявкам и перейти на проектный подход в закупках, когда те или иные закупки привязываются к выполняемым предприятием проектам и расходы и денежный поток определяются не целиком по предприятию, а в разрезе каждого проекта.
   Определяя практические результаты проекта внедрения, вы должны понимать, что не всё можно сделать сразу и на «отлично». Иногда стоит выбрать долгую дорогу поэтапного внедрения и удовольствоваться умеренным промежуточным результатом, для того чтобы предприятие как можно быстрее получило практическую отдачу от внедряемой системы и потраченных денег.
3. Придётся столкнуться с негативной реакцией со стороны персонала компании. Инициатором проекта зачастую является тот или иной руководитель предприятия, и это не всегда генеральный директор или владелец бизнеса. В рамках данного проекта он охотно сотрудничает, а иногда и вынужден вмешиваться во внутренние дела других подразделений. Это вмешательство почти всегда воспринимается враждебно в силу нескольких причин:
   • у сторонних подразделений уже есть свои руководители, поэтому необдуманное внешнее вмешательство чревато конфликтом интересов и ухудшением управляемости;
   • автоматизация и постановка учёта на предприятии иногда влечёт за собой увеличение объёма работ сотрудников: теперь нужно придерживаться определённых регламентов — например, заполнять и согласовывать заявки на оплату и закупку, заранее планировать свою работу, отчитываться о сделанном и т. д. Это мало кому доставляет удовольствие;
   • сроки принятия решений из-за выноса их за пределы локального отдела зачастую возрастают.

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

Посмотрите инструменты для решения задач управления предприятием на сайте 1С:Консалтинг

Правила выполнения проектов автоматизации

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

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

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

Проект автоматизации крупных предприятий — это многоэтапный процесс, некоторые шаги которого не всегда понятны заказчику. Поэтому давайте разберём особенности этапов такого проекта, например, если бы речь шла о внедрении системы «1С:ERP Управление предприятием 2» на каком-то предприятии. Мы разберём ситуацию, когда проект выполняется подрядным способом: есть заказчик проекта и исполнитель работ.

Этапы такого проекта автоматизации следующие:

1. Подготовка функциональной модели будущей автоматизированной системы. На данном этапе происходит создание контрольного примера, демонстрирующего заказчику то, как проект будет работать в новой программе. В случае, если типовой функционал системы не соответствует требованиям заказчика, это фиксируется. В дальнейшем эти несоответствия будут доработаны (запрограммированы) на основании составленных и согласованных технических заданий на модификацию типовой программы.
2. Настройка программы в соответствии с функциональной моделью.
3. Доработка типового функционала «1С:ERP» в части несоответствий типового программного продукта потребностям предприятия.
4. Подготовка инструкций и обучение пользователей работе с программой на основе контрольного примера функциональной модели.
5. Подготовка правил перехода на новую учётную систему и переноса входящих остатков. Этап также включает описание правил интеграции новой системы с текущими, уже используемыми программами.
6. Перенос начальных данных в соответствии с правилами перехода.
7. Настройка и запуск обмена данными с существующими учётными системами.
8. Опытная эксплуатация системы, возможно, параллельно с существующей системой учёта под контролем специалистов фирмы подрядчика.
9. Промышленная эксплуатация системы силами сотрудников предприятия заказчика.

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

Этап 1. Подготовка функциональной модели будущей автоматизированной системы.

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

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

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

1. Заказчик не знаком с функционалом предлагаемой программы и не может оперативно понять, устраивает ли его тот или иной блок, и, как следствие, при приёмке системы в работу вдруг выясняется, что ожидания были совсем другие, а исполнитель «обманул» заказчика. В данном случае рекомендуется перед началом моделирования запросить у исполнителя обучающий курс работы с программой — это наилучший вариант, который позволит заказчику получить определённые базовые навыки и понять общую концепцию предлагаемого программного решения. В дальнейшем при функциональном моделировании заказчик сможет сконцентрироваться только на собственной специфике и сложных участках учёта.
2. Уход в ненужные детали: этап функционального моделирования всё-таки ограничен по времени, поэтому все варианты тех или иных операций зачастую невозможно увидеть. Что это значит на практике? В системе есть, например, документ реализации товаров и услуг. В целом, это понятная операция, но могут быть отдельные контрагенты, у которых может быть какой-то «хитрый» договор поставки или сложный график оплаты или очень сложная система скидок. Если мы будем перебирать все маргинальные варианты реализаций на этапе функционального моделирования, то на остальное времени может и не хватить. Функциональная модель всегда будет иметь «дыры» в своей структуре или потребуется дополнительное финансирование для продолжения моделирования. А если предположить, что в процессе моделирования у заказчика что-то меняется, появляются новые варианты учёта, которые также детально описываются, — этап 1 может оказаться неисполнимым.
   Избежать этой ошибки просто: по нашему опыту, если в функциональной модели охвачено 80% учётных операций, то этого достаточно. Если вдруг в процессе опытной эксплуатации будет обнаружено, что часть функционала программы требует доработки под какие-то особые случаи учёта, то производится актуализация функциональной модели, пишется техническое задание на доработку, и программа дорабатывается. Это делается из бюджета этапа опытной эксплуатации, но в любом случае, эти деньги пришлось бы потратить — или на этапе доработок, или на этапе опытной эксплуатации.

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

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

Этап 4. Подготовка инструкций и обучение пользователей работе с программой.

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

Важный момент: этап обучения практически всегда оставляет у заказчика некоторое чувство неуверенности в том, что он действительно научился работать с программой. Эта неуверенность транслируется в жалобы о том, что обучали мало, обучали плохо и т. д. У сотрудников исполнителя противоположное мнение: он провёл запланированное обучение и считает, что его плохо слушали. Как разрешить этот конфликт?

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

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

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

Этап 8. Опытная эксплуатация системы

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

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

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

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

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

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

* * *

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

Комментарии 0