Автоматизация без дураков

Александра Гнатуш, журнал "IT Manager"
 

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

Итак, вы решили внедрить на своем предприятии систему автоматизации бизнес-процессов. Прежде чем искать исполнителя, нужно уяснить некоторые принципиальные моменты. Главный из них – внедрение должно быть действительно необходимо, то есть иметь экономическое обоснование. При этом речь может идти об автоматизации бизнес-процессов, тогда его цель — повышение надежности и оперативности предоставления информации и выделение большего времени сотрудников на ее анализ, а не на обработку. Кроме того, цель автоматизации может состоять в реорганизации бизнес-процессов. В любом случае стоимость внедрения достигает 1-2% от месячного оборота компании (разумеется, речь идет о комплексной автоматизации). Если же бизнес-цели не ясны или бюджет вашего предприятия просто не выдержит рыночной цены внедрения, то лучший выход — отложить подобное мероприятие. 

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

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

Маршрут правильного движения

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

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

Этап 2. Формализация бизнес-процессов. После понимания задач можно переходить к следующему этапу — постановке задач на автоматизацию. Кратко - какие задачи будут автоматизированы и как. В ходе данного этапа составляются схемы движения информации (по одной на функциональную область — планирование продаж, закупка, хранение и т. д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовки и IT-менеджеры. В результате данного этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений компании. Таким образом, это фактически этап постановки задачи.

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

Этап 4. Техническое задание. Опираясь на утвержденную постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ — «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов — «собственниками бизнес-процессов». В задании детально описываются все объекты информационной системы, их поведение и т. д. И чем подробнее будет ТЗ, тем лучше. На этом этапе очень важен процесс документирования, чтобы потом не возникали проблемы расхождения взглядов компании-клиента и внедряющей стороны.

Этап 5. Кодирование. После утверждения ТЗ можно приступать к кодированию. Это дело внедряющей организации.

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

Этап 7. Обучение пользователей. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это означает, что сотрудники предприятия будут вынуждены работать по-новому. И проблема состоит не только в том, что их нужно известить о грядущих изменениях и научить работать в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Другими словами, нужно учесть и человеческий фактор.

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

Экипировка

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

У фирмы-внедренца должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? Внедренец готов работать по любой предложенной заказчиком форме? Значит, это плохой внедренец. Нельзя плясать под дудку заказчика, ведь он не профессионал. Только представьте - приходите вы к врачу, а он вас спрашивает: «Как будем лечиться?». То есть нужен еще один документ. В начале каждого этапа заказчик должен утвердить формат документа результата по данному этапу. Хорошо, если этот формат будет совпадать/коррелировать с общепринятыми — ГОСТ, IDEF. Цель - предсказуемость результата.

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

Сроки

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

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

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

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

Стоимость

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

Способ 1. Авантюрный. Внедрение всегда производится с целью оптимизации бизнеса, и результатом внедрения будет увеличение прибыли автоматизируемого предприятия либо за счет расширения бизнеса, либо за счет сокращения потерь, либо за счет и того и другого. Вот на некоторую долю прироста прибыли, полученного в результате автоматизации, стороны и договариваются. Этот способ достаточно редок. Солидная внедряющая фирма на это никогда не пойдет по следующей причине - нести прямые затраты ей придется сейчас (время, потраченное на внедрение специалистами компании), а окупятся они в будущем или нет, будет зависеть от персонала заказчика. То ест, проконтролировать этот процесс нельзя. Риск огромен.

Способ 2. Проектный. Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Способ действительно ясный, но вот последствий этой ясности заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам. В таком случае стороны четко оговаривают, что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование — кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. Но что произойдет, если после подписания договора и постановки задачи заказчик вдруг обнаружит, что по какой-либо причине стоящие задачи изменились и часть заявленных в постановке задач в том виде, в каком они утверждены внедренцем, ему уже не нужна? Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право сделать ненужную работу и добиться оплаты ее договорной цены. Кроме того, коль скоро сроки работ определены, внедряющей фирме не выгодно их растягивать — норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать заказчику затянуть сроки (увеличить скорость принятия решения заказчиком). Иными словами, при проектном способе реальную ответственность берут на себя обе стороны, но одна из сторон редко отдает себе в этом отчет.

Способ 3. Рамочный договор о сотрудничестве. Жизненность этого способа определяется его гибкостью. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договариваются, что новые задачи можно формулировать и выполнять оговоренным способом, по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. Меньшая жесткость - меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит, гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.

Управление

Процесс управления практически любым объектом можно представить циклом (рисунок). Если, скажем, мы управляем кораблем, то Целеполагание — это принятие решения доплыть, например, из Ливерпульской гавани в Бразилию; Планирование — это решение о том, что для пополнения запаса горючего нам необходимо зайти в промежуточный порт, например, на Кубу; Исполнение — это собственно плавание; Контроль — это необходимость прочитать название порта и убедиться, что попали именно на Кубу, а не в Каир; Анализ — соотнесение желаемого местонахождения с действительным; Формирование управленческого воздействия — оргвыводы и приказ заменить проштрафившегося штурмана; Корректировка — изменение планов или целей в зависимости от величины промаха, ну и так далее. Более того – каждая фаза в отдельности должна быть тоже управляема, а значит, и иметь свои целеполагание, планирование, исполнение, контроль и анализ.

Автоматизированная система управления в общем случае должна автоматизировать именно этот цикл, так как именно он является определением термина «управление». Вопрос в том, какие фазы управленческого цикла подлежат автоматизации? Достаточно очевидно, что не целеполагание и корректировка, которые пока являются прерогативой человека, поскольку на этих этапах разрабатывается/корректируется миссия, стратегия предприятия, его глобальные планы (имеющие в основном качественную оценку) или производится изменение плана — процесс, тоже не подлежащий алгоритмизации. На всех же остальных стадиях автоматизация весьма и весьма уместна. В любом случае сбои на любой стадии управления приводят к тому, что объект становится плохо или вовсе неуправляемым.

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

Разберем фазы, подлежащие автоматизации, подробнее.

Фаза планирования

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

1. Финансовый директор делает в системе пометку о начале планирования.
2. Автоматически всем пользователям системы рассылается сообщение о начале планирования следующего периода, его сроках и deadline предоставления плана.
3. IT-менеджер, в числе прочих ответственных, получает указанное сообщение и начинает планировать, допустим, следующий месяц.
4. Он указывает номер декады (недели, точную дату — все зависит от выбранной модели), статью расхода и сумму. Причем заранее составлена проекция менеджеров, участвующих в планировании, на статьи затрат. Это значит, что IT-менеджер никак не сможет планировать налоги или зарплату основного производственного персонала, поскольку ему это запрещено. Но выбрать статью — оргтехника и провести по ней $600 (поддержание и текущий ремонт) он сможет.
5. Завершив планирование, менеджер оценивает свои планы, что-то меняет и ставит отметку.
6. Автоматически система формирует сообщение, что тогда-то такой-то IT-менеджер предоставил все планы.
7. Финансовый директор, таким образом, получает консолидированную информацию от всех отделов.
8. Затем, как правило, полученные планы не удовлетворяют финансового директора (а может, генерального директора или акционеров). Финансовый директор или дает задания подразделениям что-то изменить, или в пределах дозволенного меняет сам. Но с автоматическим предупреждением всех заинтересованных лиц.
9. В результате в системе формируются приемлемые для всех сторон (естественно, с учетом их веса) бюджеты расходов и платежей.
10. Финансовый директор закрывает указанный период для планирования, после чего всем автоматически рассылаются оповещения об утверждении (невозможности дальнейшего изменения) бюджетов.

В результате сформированы четкие планы расходов и выплат предприятия на предстоящий период. На практике процедура разработки и утверждения подобных планов занимает от 3 до 10 дней в зависимости от сложности бизнеса и скорости принятия решений. Учитывая требования конкретного менеджмента, указанная процедура может быть проще или сложнее. Например, возможно лимитирование определенных статей (в абсолютных величинах или в процентах от других статей) — на рекламу нельзя тратить более 6% всех поступлений от продаж и т. д.

Фаза выполнения

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

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

1. Подчиненный IT-менеджера (или он сам) вводит в систему заявку на выплату, допустим, $630, указать статью — поддержание оргтехники, и способ оплаты — безналичный. По плану же на данную статью полагалось $600.
2. Менеджер видит перерасход — $30 (в общем случае — величину неизрасходованного остатка по статье) и отсылает такую заявку финансовому директору.
3. Финансовый директор получает сообщение о новой заявке от IT-менеджера, видит перерасход по ней и текущий остаток денежных средств на том счете, с которого она будет уплачена.
4. Если финансовый директор согласен, он утверждает заявку и продолжает ее движение по маршруту. Если не согласен — отклоняет, что означает возврат заявки к ее отправителю с указанием причины отвода.
5. В случае утверждения заявка попадает к бухгалтеру, который, после получения необходимых документов (счета, акта, счета-фактуры и т.д.), ставит свою визу — «проведено».
6. Дальше бухгалтер по банку одним движением на основании заявки печатает платежное поручение. Заявка получает статус — «удовлетворена».

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

Фаза контроля

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

Фаза анализа

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

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

Для того чтобы все вышесказанное обобщить, рассмотрим два конкретных примера.
1. Компания Y занималась крупной оптово-розничной торговлей товарами определенной группы. Перед топ-менеджерами была поставлена задача увеличения прибыли. Топ-менеджеры решили выяснить, какие товарные позиции приносят большую прибыль. Через месяц они это выяснили и решили убрать плохо продающиеся товары. Затем они выбрали несколько самых ходовых позиций и увеличили по ним закупки, а от остальных отказались. В результате компания осталась без ассортиментных позиций. При отсутствии ассортиментного минимума резко снизились продажи и самых ходовых товаров — их стали покупать у конкурентов.
2. Компания Z занималась крупной оптово-розничной торговлей товарами, импортируемыми из-за границы. Так же, как и в предыдущем примере, перед топ-менеджерами была поставлена задача увеличения прибыли. Рынок к этому моменту уже устоялся, и топ-менеджеры решили, что единственная возможность качественного улучшения ситуации находится не на уровне бюджетных решений (увеличение числа и пропускной способности каналов поставок, конкурентное снижение отпускных цен и т. д.). Следующим их шагом был анализ выполнения всей логистической цепочки доставки товара:

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

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

Было решено ввести еще один этап (между этапами 2 и 3). Этим новым звеном стал этап Согласования. Появились две новые должности:
1) менеджер, отвечающий за согласование отклонений с поставщиком. Он несет ответственность за то, что поступит именно согласованный товар;
2) менеджер, отвечающий за то, что согласованный товар будет востребован и продан филиалом.
Этого оказалось достаточно для существенного сокращения потерь.

Коэффициент автоматизации

Автоматизация нужна для повышения эффективности бизнеса. Каким образом?

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

Коэффициент автоматизации (AQ) обратно пропорционален количеству алгоритмизируемых, но не автоматизированных операций.

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

Поэтому существует опасность недоавтоматизации. Предположим, на некотором предприятии в системе была реализована поддержка планов, учета, планирования и контроля. Вроде бы хорошо. В числе прочих составлялся бюджет выплат. Но на самом деле учет выполнения планов велся без предварительного контроля, т. е. при плане выплат в 100 единиц сотрудник мог сделать платеж на 500, и на следующий день менеджер видел результаты контроля — отклонение — 400. Правда, было уже поздно, так как отменить действие невозможно. Поэтому перед любым платежом сотруднику приходилось сопоставлять план выплат, произведенные выплаты и намеченную выплату, а хранились они в разных подсистемах и т. д. и т. п. В итоге – затрачено лишнее время, появляется раздражение и ошибки. А достаточно было просто проработать механизм лимитирования, и при попытке превышения лимита оператор получал бы соответствующее уведомление и рекомендацию отправить заявку на согласование и утверждение. То есть система с необходимой степенью гибкости реагировала бы, и больше того — регламентировала бы деятельность оператора.

Но существует и другая опасность - опасность переавтоматизации. Предприятие купило престижную информационную систему (западного производства), вложив в нее сотни тысяч долларов. Номенклатура товаров — около 10 000, поставок — до 500 в день. И вместо обычных кладовщиков предприятие вынуждено взять на работу квалифицированных программистов для ввода накладных и подготовки отчетности. А все потому, что в этой КИС товар представлялся двенадцатизначным кодом, и пользователю каждый раз требовалось набирать в документах эти цифры, специальным образом ежедневно расшифровывать из данных штрих кодового оборудования, копировать и импортировать файлы, и снова преобразовывать коды в отчетах. И любая ошибка или несвоевременное выполнение операций приводили к серьезным проблемам. То есть оперативность и достоверность информации, которую предоставляла информационная система, зависела от такого числа человеческих факторов, что сбои фактически были запланированы.

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

Решения

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

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