"Блеск и нищета" предпроектного обследования при проектировании и внедрении ERP-систем на предприятии

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

Содержание

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

До появления ЭВМ в качестве инструментальной базы управления были задействованы расчеты, выполняемые вручную. Позднее появились арифмометры и калькуляторы, а еще позднее - соответственно ЭВМ. Вычислительные возможности ЭВМ послужили основанием для создания автоматизированных систем управления предприятиями (АСУП), которые активно внедрялись и эксплуатировались на российских предприятиях уже с середины 60-х гг. ХХ в.

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

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

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

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

Первым среди таких стандартов можно назвать ГОСТ 24.601-86 "Автоматизированные системы. Стадии создания". В данном ГОСТе первая стадия называлась "Исследование и обоснование создания АС" и включала два этапа:

1) обследование (сбор и анализ данных) автоматизированного объекта, включая сбор сведений о зарубежных и отечественных аналогах;

2) разработка и оформление требований к системе (технико-экономическое обоснование, тактико-техническое задание, заявка).

Преемником этого ГОСТа стал ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания", где первая стадия называлась "Формирование требований к АС" и включала три этапа:

1) обследование объекта и обоснование необходимости создания АС;

2) формирование требований пользователя к АС;

3) оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания).

В этих ГОСТах обратим внимание на два момента. Первое - это "обоснование необходимости создания АС", второе - "формирование требований к АС".

В годы, когда создавались данные ГОСТы, персональные компьютеры на рабочих местах управленческого персонала в нашей стране еще широко не использовались и оставались "экзотикой" (небольшая мощность, высокая цена и другие ограничения). Проектирование АСУП все еще было ориентировано на применение больших ЭВМ. Так как любой проект связан в первую очередь с финансовыми затратами, то для определения объема выделяемых для него средств следовало в обязательном порядке их обосновать. Поэтому вопросы, касающиеся обоснования необходимости создания автоматизированных систем, должны были быть подкреплены экономическими расчетами, которые доказывали экономическую эффективность от их внедрения.

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

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

Последний отечественный стандарт рассматриваемого типа - ГОСТ Р 53622-2009 "Информационные технологии. Информационно-вычислительные системы. Стадии и этапы жизненного цикла, виды и комплектность документов".

В этом стандарте термин "автоматизированная система" заменен на термин "информационно-вычислительная система" (ИВС), аббревиатура "АСУ" трактуется как "автоматизированные информационные системы управления". Кроме того, использовано понятие "жизненный цикл ИВС" и содержание раздела "Основные стадии и этапы жизненного цикла ИВС" приводятся в контексте жизненного цикла создания (разработки) и использования ИВС.

Начальным в данном разделе назван этап "Проведение научно-исследовательских работ - обоснование состава решаемых задач, структуры и состава ИВС и подготовка проекта ТЗ на создание (разработку) ИВС", который включает в себя две работы:

1) обоснование требований к ИВС и ее составным частям;

2) подготовку проекта ТЗ на создание (разработку) ИВС (составной части ИВС).

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

Кроме отечественных стандартов по обозначенной тематике существует международный стандарт, интерпретированный в российской редакции как 180ДЕС 15288:2002 "Информационная технология. СИСТЕМНАЯ ИНЖЕНЕРИЯ. Процессы жизненного цикла систем".

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

Выводы

Анализ четырех стандартов по обозначенной тематике позволяет сделать следующие выводы:

1. Между всеми приведенными стандартами наблюдается явная преемственность и в каждом из них отражена совокупность работ, связанных с формированием требований в ЕRР-системе. Данный класс систем можно рассматривать как разновидность автоматизированной системы или ИВС.

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

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

Интересно отметить, что в начале 90-х гг. ХХ в. в области проектирования систем класса ERP произошли изменения, которые можно охарактеризовать следующими особенностями:

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

2. Образовался рынок программных продуктов (ПП), и систему любого класса и назначения можно приобрести за деньги в уже пригодном для эксплуатации виде. Появилось также понятие "коробочный ПП". Многие ERP-системы позиционируются на рынке как "коробочные", т.е. готовые к непосредственному внедрению без каких бы то ни было доработок. Однако в реальности в связи со спецификой предприятий это становится невозможным и требуется адаптация или доработка (иногда достаточно значительная) уже готовой системы. Еще один вариант решения - настройка параметров системы под нужды конкретного предприятия. Например, система R/3 (класс ERP-систем) имеет порядка нескольких десятков тысяч настраиваемых параметров. Но порой и функции настройки неспособны решить отдельные бизнес-задачи. Тогда систему все равно приходится дорабатывать.

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

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

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

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

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

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

Предпроектное обследование объекта автоматизации необходимо проводить в следующих случаях:

1) создание автоматизированной системы по "индивидуальному заказу";

2) внедрение готовой системы;

3) внедрение дополнительных модулей "родной" системы или "иногородней";

4) модернизация существующей системы;

5) внедрение дополнительных систем к системам, уже функционирующим на предприятии.

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

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

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

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

Размещено на Allbest.ru