Внедрение систем автоматизации. Волки сыты и овцы целы

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

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

Итак, что такое система автоматизации управления предприятием? А все что угодно! Я искренне уверен, что здесь следует руководствоваться законом рынка:  «Покупатель всегда прав». Каким видит свой инструмент заказчик, таким и следует его создавать. Нет, конечно, большая часть работы исполнителя - разносторонне конструктивно критиковать и вносить предложения по корректировке и дополнению видения заказчика, указывать на проблемы, которые не предусмотрел клиент. Но в первую очередь – слушать! Слушать руководителей и простых сотрудников, изучать их работу и пожелания досконально, а не навязывать готовое типовое решение. Возможно, окажется, что по результатам досконального изучения нужд заказчика решение можно будет реализовать за счет типового готового программного продукта. Но необходимо сознавать, что работы все равно еще предстоит много, – не следует недооценивать сложность и цену автоматизации.

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

Первые шаги. Анализ рынка

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

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

Цена вопроса

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

Картина теперь представляется безрадостной. Мало того, что реальные сроки автоматизации существенно отличаются от ранее ожидаемых сроков внедрения по принципу «купил – проинсталлировал - готово», так еще и цены заоблачно высоки. Ну и к продуктам претензия – зачем покупать типовой программный продукт, если его все равно придется серьезно переделывать? Если к предложению прикладывают список "внедренных АСУП", советую не полениться, выбрать несколько компаний из середины списка и завязать с ними электронную переписку, чтобы кратко выяснить, что действительно в итоге представляет собой готовое внедренное решение у них.

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

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

В итоге каждый заказчик приходит к своим выводам. Некоторые предприятия принципиально отказываются от идеи автоматизации и продолжают вести учет в MS Excel, другие соглашаются на кабальные условия и часто не удовлетворены процессом автоматизации еще до его начала (как следствие – затянутый или несостоявшийся проект). Есть и более экзотические решения – отказ от всех предложений готовых решений и автоматизация с нуля (например, собственной группой программистов).

Самостоятельное внедрение

Существует еще один вариант – автоматизация «собственными силами» (т.е. нанимаемыми в штат программистами и внедренцами), но за счет готового решения. У такого варианта есть серьезные преимущества: собственные штатные сотрудники глубже вникнут в задачи предприятия и произведут систему автоматизации, максимально отвечающую бизнес-процессам заказчика. Кроме того, собственные сотрудники обходятся предприятию значительно дешевле и всегда доступны на расстоянии «поднятой трубки».

Но есть и отрицательные стороны: стоимость программного продукта по-прежнему входит в цену вопроса. А на период внедрения требуется временно "усилить" IT-персонал "сильными" и "дорогими" специалистами.

Что делать заказчику с "дорогими" специалистами после внедрения? Этот вопрос следует обсудить еще до начала работ. Большинство исполнителей таких работ и не рассчитывают состариться на одном предприятии. Они с самого начала "идут на проект", который собираются добавить в свое резюме для поиска новых работ. Желающие продолжить работу должны будут доказать заказчику свою необходимость. Конечно, в первую очередь, это - поддержка системы и ее доработка.

Нанять одного «зеленого» администратора сети и одного «программиста» взамен специалистов группы внедрения может быть опасно и неэффективно для предприятия.

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

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

Бюджет

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

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

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

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

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

Сроки реализации проекта

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

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

Порядок внедрения

Большое внимание следует уделить последовательности охвата системой автоматизации участков предприятия. Обычно при внедрении систем автоматизации на предприятии подход осуществляется по принципу "сначала решим свои проблемы, потом прикрутим бантики". Так, если руководство хочет в первую очередь получить автоматизацию производства, то направляет внедренцев на этот участок, пренебрегая другими. Нередко руководители сами указывают приоритетные для внедрения участки своего предприятия (например, по подразделениям). Что ж, это выбор, с которым следует считаться! Однако необходимо сознавать, что в итоге такая автоматизация выйдет дороже.

Попытаюсь объяснить почему. Информация на каждом участке предприятия обладает собственной детализацией. Приведу в пример информацию о физическом лице - сотруднике предприятия. Сотрудник до приема на работу передает информацию в HR-отдел, при приеме на работу представляет все свои данные в отдел кадров, отдельно информацию о личных налоговых данных и окладе - в бухгалтерию. На предприятии его зачисляют в подразделение. Когда автоматизируется производство, обязательно указываются ответственные за участки, производственные бригады, МОЛы. Значит, карточка данного физического лица обязательно будет зарегистрирована в системе. Но на этом участке производства никто не будет регистрировать паспортные данные или ИНН сотрудника, - там этой информацией попросту не пользуются.

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

Поэтому, если на предприятии хотят провести полную автоматизацию с меньшими расходами, следует попытаться производить работы в таком порядке, чтобы соответствовать информационным потокам существующего бизнес-процесса. Чтобы  ответить на этот вопрос, нужно выяснить, на каком участке предприятия находится ответственность за определенные сведения. Данные физических лиц (в т.ч. ИНН) обязательно сопровождает отдел кадров или расчетчики заработной платы. Данные контрагентов (ЕГРПОУ) - финансисты или бухгалтера. Номенклатуры – отдел снабжения. Товары – отдел производства. И т.д.

Соглашение сторон

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

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

Риски проекта

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

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

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

20% - это излишняя экономия заказчика. Система не получила вовремя всех ресурсов, достаточных для ее нормального функционирования. Основные причины:

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

20% - неорганизованность заказчика. При внедрении или эксплуатации системы проявились фатальные для нее проблемы заказчика:

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

15% - саботаж различного характера. При внедрении или эксплуатации системы проявился человеческий фактор:

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

15% - ошибки/несостоятельность группы внедрения, неверный ход самого процесса внедрения или недостатки технического обеспечения. При внедрении были допущены серьезные ошибки и просчеты. Трудно исправимые или неисправимые:

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

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

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

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

К выполнению этой работы подходят по-разному. Есть очень детализированные технические задания размером с фолиант и шаблонные ТЗ на пару десятков страниц, в которых лишь несколько абзацев подправлены «под заказчика». В каждом случае содержание и стиль ТЗ тоже различается: кто-то старается строго придерживаться стандартов описания, а кто-то излагает вольным стилем и «на своей волне». Для того чтобы определиться с необходимым уровнем детализации ТЗ, необходимо ответить на элементарный вопрос: «Что произойдет далее с этим ТЗ, кто его будет читать?».

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

Функциональный лист

При производстве работ по автоматизации во время изучения бизнес-процессов следует заполнить "функциональный лист". Кратко - это таблица, регламентирующая уровень доступа и ответственности для каждого ключевого пользователя или каждого АРМ в будущей системе автоматизации ко всем возможным функциям в этой системе. Одно измерение листа – полный перечень функций, которые будут реализованы системой автоматизации. Второе – перечень «ключевых пользователей. На пересечении этих множеств можно указать параметр – указывающий на то, как именно будет управлять данной функцией данный пользователь. Например:
0 – Отсутствие доступа;
1 – Доступ только для чтения. При этом данная функция специально в интерфейсе пользователя не размещается. Например, у пользователя нет доступа к реестру документов, но он может их просмотреть в качестве расшифровки отчета;
2 - Доступ только для чтения. При этом эта функция размещается в интерфейсе пользователя (в его обязанностях - наблюдать за данным участком);
3 – Доступ для редакции;
4 – Доступ для администрирования, управление данным участком.

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

Затем проводятся собеседования с «ключевыми» пользователями, которых назначит руководитель подразделения для каждого участка будущей системы автоматизации. Так заполняется «паспорт АРМ», в котором отмечается все необходимое (функции, ответственность). По результатам анализа паспортов рабочих мест и формируется «функциональный лист». ФЛ согласуется с руководителем подразделения. Вносятся изменения, если обнаруживаются ошибки или недочеты. Вносятся изменения от модели бизнес-процесса «как есть» (AS IS) к модели «как будет» (TO BE). Для каждого пользователя формируется "Персональный Функциональный лист», который в свою очередь передается пользователям. После их согласия описанные функции будут внесены в должностные инструкции на предприятии (к моменту старта работы системы автоматизации).

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

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

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

Сергей Жигуненко/Специалист по внедрению и развитию систем автоматизации. Украина