На войне как на войне

Архив

Статья продолжает тему "Автоматизация". Авторы - независимые консультанты, специализирующиеся на совмещении интересов предприятий, желающих себя автоматизировать "за 30 копеек", и автоматизаторов с совершенно противоположными целями.

Статья продолжает тему «Автоматизация» («КТ» #419). Авторы - независимые консультанты, специализирующиеся на совмещении интересов предприятий, желающих себя автоматизировать «за 30 копеек», и автоматизаторов с совершенно противоположными целями. В статье используется многолетний опыт внедрения систем управления предприятиями.

Сама статья смыкается не только с темой автоматизации деятельности предприятия как таковой, но и с более широким спектром проблем оптимизации работы любой компании. То, что, по мнению Константина Березина и Юрия Ткаченко, должен делать системный аналитик, на самом деле, входит в сферу интересов CIO (chief information officer), только на более высоком уровне. Тему, посвященную CIO, мы планируем опубликовать в одном из ближайших номеров.

Автоматизация предприятия - очень рискованное с экономической точки зрения дело. В статье «Чайники для систем класса ERP» Сергея Питеркина и Владимира Гуриева («КТ» #419) упомянуто, что более четверти внедрений самой популярной информационной системы для крупных предприятий R/3 от компании SAP закончились провалом, а у других производителей подобных систем дела вряд ли идут лучше. Но это только цветочки. Многочисленные исследования, проводимые в течение ряда лет зарубежными специалистами [1], показали, что только очень небольшой процент пользователей MRP- и ERP-систем полагают, что они их успешно используют. То есть большинство из успешно установленных систем не используется на практике ¹. Причем имеются в виду не только предприятия-монстры, но малые и средние фирмы.

Возникает резонный вопрос: а можно ли вообще успешно провести автоматизацию управления предприятием? Опыт показывает, что можно. Если знаешь правила игры. И пусть о них начнут рассказывать сами же автоматизаторы (информация взята из материалов семинаров для автоматизаторов-партнеров «1С» ²):

«Существуют несколько способов оценки консультационных услуг. Два основных - следующие:

1. с клиентом подробно оговаривается объем работ, сроки и сумма оплаты;

2. осуществляется повременная оплата работ.

Опыт показал, что единственно возможным вариантом для консультанта является второй вариант, поскольку при использовании первого варианта у клиента ВСЕГДА появляются дополнительные требования. Можно, конечно, написать сверхподробное техническое задание (ТЗ) и каждый день подписывать акты сдачи-приемки, но, мне кажется, что это нереально».

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

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

Может, стоит поручить написание «сверхподробного» ТЗ внедренцам? В той же брошюре партнерам фирмы «1С» дается следующий совет:

«Как уговорить клиента на повременную оплату? Было придумано специальное коммерческое предложение, в котором клиенту как бы предлагалось два варианта, но реально он мог бы выбрать только один».

С повременной оплатой, естественно. То есть вариант с написанием «сверхподробного» ТЗ и оплатой за «весь объем работ» всерьез внедренцами даже не рассматривается. У них просто нет специалистов, которые досконально разбирались бы в вашем бизнесе. Поэтому они будут стремиться подогнать ваш бизнес, деятельность вашего предприятия под те знания, которыми владеют, а не наоборот. А где гарантия, что их знания о вашем бизнесе лучше ваших? Точно так же поступают любые опытные внедренцы, а не только партнеры «1С». Бизнес у них один и методы его ведения схожие. Ведь не их вина, что в подавляющем большинстве случаев заказчик сам не знает, чего хочет, а постановку задачи приходится воспринимать на слух, многократно уточняя в процессе работы существенные детали. Очень часто заказчик спустя некоторое время полностью меняет задание, и всю работу приходится начинать заново.

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

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

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

«Системный аналитик несет ответственность за анализ проблем и информационных потребностей организации перед внедрением новой системы обработки данных или реконструкцией старой. Он работает в сотрудничестве с руководителями подразделений и специалистами и должен иметь представление о маркетинге и производстве, а также бухгалтерском учете и планировании. Системный аналитик должен составить требования к информации и разработать новую модель информационного потока, который можно автоматизировать. После проектирования системы аналитик определяет необходимое аппаратное обеспечение, пишет спецификации, которым должен следовать программист при разработке программного обеспечения, и формулирует процедуры обучения, которым должны следовать в организации при внедрении новой системы» [3]. Кроме этого, системный аналитик должен руководить подготовкой ТЗ на программу, проведением тестирования готовых модулей программы, проверять их соответствие ТЗ, собирать замечания пользователей к программе, отслеживать устранение замечаний, закрывать этапы разработки.

Сначала системный аналитик будет проводить опрос руководителей подразделений и специалистов - будущих пользователей системы. Цель - сбор требований к программе.

На основании собранной информации делается описание деятельности предприятия. Требования отдельных пользователей объединяются в едином обобщенном представлении: «концептуальной модели».

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

1. Сотрудник А принимает решение на осуществление какого-либо действия.

2. Сотрудник А поручает сотруднику Б выполнить какое-либо действие. Поручение дается в устной, письменной или электронной форме. На схеме это документ 1. Поручение содержит исчерпывающий для сотрудника Б перечень сведений, необходимый для осуществления действия.

3. Сотрудник Б выполняет это действие. На основе действия формируется отчет о проделанной работе. Отчет также содержит исчерпывающий перечень всех сведений, необходимых сотруднику А для оценки проделанной работы.

4. Данные отчета сравниваются с Базой знаний (нормы, нормативы, стандарты, планы организации, оценка эксперта и т. д.).

5. Сотрудник А получает информацию о проделанной работе и оценку ее эффективности, полученную путем сравнения результатов работы с Базой знаний.

6. На основе оценки результатов работы сотрудник А принимает решение о дальнейшей работе.

7. Сотрудник А разрабатывает новый документ для сотрудника Б либо переходит к другой подобной схеме работы с другими сотрудниками.

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

Документация должна легко читаться и не иметь разночтений. Очень полезно нанять профессионального технического писателя для ее подготовки.

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

Для скорейшей отдачи от автоматизации необходимо разбить будущую информационную систему на максимальное число отдельных модулей. Критерии разбиения:

1. Экономическая выгода запуска любого из этих модулей в отдельности.

2. Возможность в будущем связать эти модули в единую систему.

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

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

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

Работа по внедрению программы строится по принципу обратной связи:

1. Системный аналитик дает ТЗ внедренцам.

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

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

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

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

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

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

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

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

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

Источники

[1] The Oliver Wight ABCD Checklist for Operational Excellence. Fourth Edition - Oliver Wight Publications., Inc., 1993.

Browne, Jimmie. Production management systems: an integrated perspective / Browne, Jimmie, John Harhen, James Shivnan. 2 ed., Addison-Wesley Publishing Company, 1996.

[2] Элементы технологии работы фирмы - 1С:ФРАНЧАЙЗИ. Методические материалы Издание 3, дополненное Декабрь, 1996. Д.И. Казачков.

[3] Albert Kagan, Marion G. Sobol, Kevin Quanrnstrorm, «Job Roles of Systems Analysts in the «Profit» vs. the «Not for Profit» Sectors», Information and Management, November 1986.

---

1 (обратно к тексту) - Вряд ли можно говорить о том, что внедренные системы вообще не используются. Как-то, да используются - хотя бы ради того, чтобы заказчик мог немного оправдать в собственных глазах значительные денежные средства, потраченные на внедрение. Однако разрыв между тем, что хотелось, и между тем, что получилось, зачастую огромен. - Прим. ред.
2 (обратно к тексту) - Продукты «1С» не имеют никакого отношения к ERP и даже к MRP (хотя некоторые системы, построенные с помощью «конструкторов» «1С», можно с некоторой натяжкой назвать MRP-системами). Тем не менее, проблемы, стоящие перед внедренцами и заказчиками систем от «1С» и ERP-систем, на самом деле, не очень сильно отличаются. - Прим. ред.