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

Введение

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

Все это, конечно, делалось и раньше – ИС такого класса были известны как АСУ и/или АСУП. А теперь называются "системами управления бизнес-процессами предприятия". Смена вывески обусловлена не изменением функций, скорее – реализацией этих же функций на вычислительной платформе следующего поколения. Ну и, конечно, требованиями времени, отказом от устаревшей (даже где-то дискредитировавшей себя) терминологии.

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

Бизнес-процессы и бизнес-функции

Определимся относительно термина "бизнес-процесс". Раньше для описания деятельности управленческого персонала употреблялись такие термины: функции управления, управленческие решения, управленческие процессы и т.п. Постепенно их начинают вытеснять новые, более емкие и короткие термины – бизнес-процессы и бизнес-функции.

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

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

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

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

 – долгосрочное планирование;

 – ведение портфеля договоров и заказов;

 – закупки комплектующих и сырья;

 – отгрузка продукции и выписка счетов;

 – техническое обслуживание и ремонт оборудования;

 – бухгалтерский учет (учет затрат на производство, платежей и поступлений платежных средств и пр.).

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

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

Нужна ли заводу ИС?

Обсуждение целесообразности создания на предприятии информационной системы для управления бизнес-процессами должно дать ответ на два вопроса:

1. Зачем нужна для конкретного предприятия компьютерная система организации бизнес-процессов? Работает ли предприятие так, что ему поможет хоть какая-то система?

2. В случае ответа типа "Да, работает (или планирует начать работать) так, что некая система ему сможет помочь", – встает вопрос: "Из чего выбирать?" ф/у

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

Масштаб и периодичность изменений могут быть различными. Важно то, что все эти изменения так или иначе обычно укладываются в "проекты", которые имеют начало, завершение и чего-то стоят. Их необходимо анализировать, просчитывать и далее – организовывать.

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

 – что и где надо покупать (сырье, комплектующие);

 – когда закупленное должно быть доставлено и подготовлено к запуску в производственный процесс;

 – какие подразделения усилить специалистами и к какому сроку надо обучить персонал;

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

От планов работы предприятия переходят к планированию деятельности всех задействованных в проекте структурных подразделений, организуется финансовое, сырьевое и технологическое их обеспечение. Далее идет фаза реализации планов – контроль, оперативное управление, составление отчетности

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

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

Не тратить денег зря

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

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

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

Что предлагает российский рынок?

На Западе применительно к системам масштаба предприятия часто употребляют термины manufacturing requirements planning (MRP), manufacturing resource planning (MRP II), busmnes management systems. Сегодня передовым по техническому оснащению заводам нужен многофункциональный программный комплекс для управления бизнес-процессами. И им есть из чего выбрать.

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

Существует достаточно большое количество ИС рассматриваемого класса, но в статье выделены прежде всего системы, адаптированные к российскому рынку, т.е. как минимум локализованные и учитывающие некоторые черты российского бухучета. Все фирмы-продавцы предъявляют потенциальным клиентам внушительные списки своих инсталляций. И что любопытно – иногда даже в России. Я полагаю, что к подобному представлению надо относиться достаточно спокойно.

Итак, R/3 – продукт фирмы SAP AG. Германская фирма (штаб-квартира ее находится в городе Вальдорфе) занимает лидирующие места в списке наиболее богатых софтверных компаний мира, стабильно входя в первую десятку. Имеет хороший бизнес в США. SAP продвигает продукты R/2 (для мэйнфреймов) и R/3 (для варианта "клиент-сервер"). В России SAP – с 1991 года, работает через собственное представительство. Для России наиболее интересен, на мой взгляд, вариант с R/3. В отношении функциональности – безусловно, самая продвинутая система (и в отношении цены – тоже). Например, в R/3 наряду со стандартными подсистемами имеются такие для нас достаточно экзотические модули:

 – индивидуальное планирование карьеры сотрудника;

 – планирование использования помещений (несколько мероприятий в помещении в один день);

 – распечатка именных нагрудных табличек.

R/3 работает на AIX, Digital Unix, HP-UX, SINIX, Solans, Windows NT (так утверждается). В отношении СУБД – ADABAS, DB2 (AIX), Informix-Online, Oracle 7.1. Для настроек и написания приложений R/3 использует оригинальный язык АВАР/4.

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

Возможности R/3 позволяют отнести ее к классу "управление отраслью" Инсталляция на 30 тысяч конечных пользователей – для R/3 нормальное явление. Самостоятельно без специальной технологии, которой обладают специалисты SAP, клиент просто не сможет заставить согласованно работать эти 30 тысяч пользователей в едином информационном пространстве. Компьютерные инфраструктуры такого масштаба для нашей страны пока не характерны.

Другие системы попроще, но тоже не для бедных покупателей.

MANMAN/X за этой системой стоит СА – третья после Microsoft и Oracle софтверная фирма в мире. В Москве в технопарке ВВЦ открыт ее офис. Фирма поддерживает партнерские отношения с российскими фирмами. МANMAN/X работает с СА Openlngres (что естественно для продуктов от СА), с Oracle и Informix (это хорошо) или вообще без базы (ISAM). Клиентский интерфейс – X-Wmdows или алфавитно-цифровой (на разных платформах).

Независимость прикладных модулей от вычислительной платформы обеспечивается драйверами (на языке С), поддерживающими взаимодействие прикладных модулей с операционной системой, базой данных, пользовательским интерфейсом и периферийными устройствами. Концепция использования драйверов является ключевым моментом в обеспечении определенной независимости прикладных модулей от различных платформ и технологий. Самостоятельно переделать драйверы пользователь вряд ли сможет. Существующие драйверы дают возможность работы под IBM AIX, HP-UX, SCO, Open VMS, Sun Solaris.

В буклете MANMAN/X написано, что стоимость минимальной конфигурации системы составляет 25 тысяч долларов, но сами представители фирмы не считают эту цифру реальной.

По степени отлаженности это, наверное, самая продвинутая и надежная система, существующая достаточно долгое время. Ожидается развитие интеграции этой ИС с другими продуктами СА: СА Visual Express, CA Visual Workbench, CA Open Road, CA Visual Realia, CA Masterpiece, CA Unicenter (все указанные продукты пока не русифицированы, о чем не надо забывать).

IFS – продукт фирмы Industrial and Financial Systems AB (Швеция). Фирма IFS хорошо известна в Скандинавии и, как это не странно, в Юго-Восточной Азии. У нас работает через российских бизнес-партнеров ("ФОРС" и "КОМ-ПЕК"). Продукт сделан на штатных средствах Oracle (SQL*FORMS 3, Report Writer, PL/SQL, PRO*C), но сейчас переходит на клиентскую часть SQL Windows фирмы Gupta. Вычислительные платформы – все, где ставится Oracle.

Система поставляется практически полностью в исходных текстах (shell'овские инсталляционные скрипты для Unix, скрипты с описанием таблиц и триггеров на SQL, тексты прикладных программ на PRO*C). Специфика наращивается также с помощью штатных средств Oracle. Изюминкой системы является, на мой взгляд, MHS (Message Handler System) – система передачи межмодульных сообщений. Можно сказать, что это специальный протокол для передачи бизнес-сообщений.

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

MFC/PRO – продукт американской компании QAD. У нас этой системой занимается CSBI ЕЕ. MFG/PRO написана с использованием средств Progress, может работать с базами данных Progress и Oracle. Продукт появился у нас недавно, и информации о нем крайне мало.

AVALON 9 – представлена в России известным системным интегратором LVS. Был всплеск рекламы, который стих, но писать эпитафию системе рано. ИС работает под Oracle или Sybase. Клиентская часть – под Windows и Motif.

Остались за кадром

Среди продуктов, не попавших в приведенный выше перечень, можно отметить следующие:

Oracle Manufacturing – линия прикладных продуктов Oracle Corp.;

Global Enterprise Manufacturing Management System (GEMMS) – продукт Datalogix Intl. Inc.;

SmartStream – продукт компании Dun & Bradstreet Software;

Point. Man – продукт Spectrum Assoc.;

SAA – продукт BPCS.

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

А что же наши?

На моем столе лежат рекламные материалы системы "МАГНАТ", разработанной в Санкт-Петербурге. В ее составе реализованы следующие функциональные модули:

 – материально-техническое снабжение;

 – сбытовые операции;

 – складской учет;

 – финансово-бухгалтерские операции;

 – собственно бухучет;

 – управление персоналом ("кадры-зарплата-труд");

 – учет основных средств;

 – планирование производства;

 – техническая подготовка производства;

 – учет производства.

Все модули разработаны с использованием средств Oracle. Стоимость собственно продукта – 6 тысяч долларов, а минимальная стоимость внедрения составляет 40 тысяч долларов. ИС "МАГНАТ" поставляется с исходными текстами.

Как работают эти системы

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

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

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

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

Модуль управления складским хозяйством

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

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

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

Дисциплина складских операций базируется на учете правил ограничения размещения. Реализуются различные способы помещения товара в ячейку: директивный, в наиболее давно освободившуюся ячейку, в ячейку с аналогичным товаром, в ячейку, наиболее близкую к скоплению аналогичного товара, и пр. Аналогично со способами поиска ячейки для изъятия ТМЦ: поиск наиболее долго лежащего товара, наиболее близкого к выходу, наиболее кучно лежащего, изъятие директивно из ячейки NN и т.п. По результатам отслеживания и анализа текущих остатков на складах возможно формирование планов возобновления запасов.

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

Модуль организации техобслуживания оборудования

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

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

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

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

"тип работы – тарифная сетка -счет для начисления оплаты";

"тип использованных материальных ценностей – счет для списания по складу".

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

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

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

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

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

Как относиться к тому, что продукт предлагается российской компанией, а не специальным представительством фирмы-производителя? Это может означать все что угодно. Например, что фирма-производитель достаточно бедна. Или что фирма-производитель не уверена в перспективности российского рынка. Или что она довольна тем, как ее интересы представляет российский компаньон. Поэтому всегда надо смотреть на контекст.

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

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

Допустим, вы хотите провести ремонт вышедшего из строя оборудования (модуль "Обслуживание оборудования"). Посылаете из модуля "Обслуживание оборудования" в модуль "Складское хозяйство" заявку на необходимые материалы и детали. На складе нужные детали кончились или предназначены для других целей. Модуль "Складское хозяйство" вам каким-то образом отвечает, что детали надо заказать. Вы (из модуля "Обслуживание оборудования" или из модуля "Складское хозяйство") формируете заявку на приобретение нужной детали на стороне и пересылаете ее в модуль "Закупки комплектующих и сырья". При размещении заказа выясняется, что нечем его оплатить (модуль "Управление финансами" блокирует отчисление денег – счет 51 пуст). И так далее.

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

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

Несколько слов о внедрении

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

 – технические средства (подбор и закупка, установка, наладка, запуск);

 – программные средства (закупка, модификация, инсталляция, настройка);

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

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

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

Здесь есть много аспектов, связанных с социально-психологическими вопросами (напряжением межличностных отношений, увольнениями, перемещениями сотрудников). На мой взгляд, неудачи проектов на ЗИЛе (система R/2, более ранний продукт SAP) и заводе им. Ильича (система ММП фирмы Hewlett-Packard) были связаны именно с такого рода причинами.

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

Проблема адаптации заключается примерно в следующем. Примерно 60-70% поддерживаемых системой атрибутов (полей БД) действительно используются в нашей практике. Остальные проценты остаются невостребованными. Но зато в российскую документацию вводится много дополнительной информации, необходимой для таможни, налоговой инспекции, банка, экспедитора-перевозчика и других организаций, контролирующих деятельность предприятия. Поэтому для того, чтобы сформировать документ надлежащим образом, необходимо включать в документы большое количество атрибутов, которых изначально в системе нет. Можно переопределить те 30-40 % полей БД, что остались без применения. Но на этих полях часто висят триггеры (числом поболее ста), которые и определяют семантику того

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

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

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

Вместо заключения

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

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