КИС’кин дом
Сага о корпоративных информационных системах и их пользователях
Елена Монахова, Игорь Альтшулер
Том 2. Часть 2. Достоинства и ограничения унификации
Довольно часто в приходящих к нам письмах встречаются вопросы типа: “Скажите, стандарты MRP II, ERP и тому подобное - это то же, что наши всем известные АСУ и АСУП, только скроенные на западный манер, или что-то совсем другое?”. Подразумевается, что если это то же самое, то почему бы не использовать собственный богатый опыт и стандарты, зачем кланяться Западу. Если нет, то в чем фундаментальное различие. Попробуем внести ясность. Прежде всего это совсем разные вещи.
Игорь Альтшулер, Елена Монахова
Не будем отрицать пророков в своем отечестве
Стандарты на автоматизированные системы, о которых вспоминают автоматизаторы-ветераны, были выпущены Государственным комитетом стандартизации и метрологии СССР в 1989 - 1990 г г. и носили название “Комплекс стандартов и руководящих документов на автоматизированные системы (ГОСТ 34.201-89, ГОСТ 34.602-89, РД 50-682-89, РД 50-680-88, ГОСТ 34.601-90, ГОСТ 34.401-90, РД 50-34.698-90, ГОСТ 34.003-90, Р 50-34.119-90)”. Подавляющее большинство отечественных программистов (из тех, кому слегка за тридцать) о них слыхом не слыхивали. Между тем их полезность при разработке крупных систем, к коим, без сомнения, относятся КИСы, видна даже невооруженным глазом. В них скрупулезно расписаны все этапы создания автоматизированных систем, используемых в различных сферах деятельности (управление, исследование, проектирование и др.), а также виды, наименования и комплектность относящихся к каждому этапу документов. Стандарты снабжены пояснением используемых терминов, приведены также их эквиваленты на французском языке. (По данному в них определению, например, “автоматизированная система (АС) - это система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных задач”. В зависимости от вида управляемого объекта (процесса) АСУ разделяются на: АСУ технологическими процессами - АСУ ТП, АСУ предприятием - АСУП и т. п. Начитавшись этих определений, народ, помнится, быстро дал разработчикам АСУ свое определение - асунизаторы.)
Как следует из названий ГОСТов, все эти документы формализуют технологию создания, внедрения и сопровождения программно-аппаратных комплексов, именуемых автоматизированными системами, и в этом их главная отличительная особенность (аналогичные стандарты есть и в ISO).
Надо понимать, что отечественные стандарты, даже самые лучшие и глубоко проработанные, были порождены системой общегосударственного планирования и управления и призваны были поддерживать незыблемость этой системы. Основная цель предприятия (и, следовательно, его АСУ) состояла в неукоснительном выполнении (а лучше - перевыполнении государственного плана). Отсюда - борьба за снижение плана любой ценой, искусственное завышение себестоимости продукции (потому что уровень рентабельности устанавливался сверху). Стандарты, таким образом, были одной из удавок, с помощью которых государство держало в подчинении предприятия (достаточно вспомнить госприемку...).
Там, за океаном
На Западе, где государство не является единым владельцем фабрик и заводов, машин и пароходов, стандарты достаточно часто имеют концептуальный или рекомендательный характер. Это скорее база, аккумулированный опыт, а не жестко указующий перст. Это компромиссы, рожденные в борьбе между производителями, под прессингом потребителей и потребительских ассоциаций. Нередко к этой борьбе примешиваются национальные интересы или интересы крупных транснациональных корпораций.
Автоматизация на западных предприятиях начиналась не потому, что этого требовало от них государство, а потому, что растущий бизнес не мог справиться с управлением материальными, финансовыми и иными потоками и начинал проигрывать в конкурентной борьбе.
Концепция MRP (Materials Requirements Planning - планирование потребности в материалах) возникла как потребность формализовать бизнес-процессы на предприятиях. Появившиеся на основе MRP программные продукты стали производить расчет номенклатуры товаров, вести учет сырья и выпущенной продукции, отслеживать основной график производства (master production schedule, MPS), чтобы своевременно определять потребность в материалах и регулировать поставки. Базирующееся на календарном (перспективном) планировании ПО выдавало рекомендации по изменению сроков, приводя в соответствие изначально заложенные в график даты с реально необходимыми.
Главное внимание в MRP-системах было сосредоточено на двух позициях:
- расчете требуемого количества сырья и материалов для производства конкретного вида продукции;
- расчете сроков, к которым они должны быть поставлены.
В случае, когда нужно было расширить номенклатуру товаров или объем производства, все данные автоматически корректировались системой с учетом того, что уже есть на складе, и того, что заказано, и просчитывалось время, необходимое для выполнения намеченных планов.
Характерное для MRP перспективное планирование подробно рассматривает, что должно быть сделано, чтобы была уверенность в том, что ресурсов окажется достаточно, когда это будет необходимо, а запросы потребителей будут вовремя удовлетворены. А дальше уже решаются конкретные задачи: “60 изделий А нужно получить к 1 апреля. Какую дату выпуска надо установить для каждого компонента при 6-дневном производственном цикле?”.
Развитием MRP стала созвучная ей концепция MRP II (Manufacturing Resources Planning), которая затрагивала уже планирование всех ресурсов производства (определение потребности в персонале, оборудовании, сырье, поставщиках и т. п.) с учетом маркетингового прогноза. Построенные на MRP II системы интегрировали данные финансовой, производственной и сбытовой сферы.
Однако традиционная для MRP II учетно-ориентированная иерархия все же держала клиента “на расстоянии” от производства. А потому не заставили себя ждать очередные методологические усовершенствования в виде ERP (Enterprise Resources Planning) - концепции, стандартизованной американским обществом APICS (American Production and Inventory Control Society), объединяющим основных действующих лиц американской промышленности. ERP-системы являются основным транзакционным механизмом, позволяющим предприятиям планировать производство с использованием компьютеризированного метода, одновременно управляющего и бизнесом, и производственными процессами. Фиксируя транзакции - т. е. счета-фактуры или производственные заказы, - такие системы отслеживают все задействованные ресурсы (финансовые, производственные, сбытовые). Роль ПО при этом возрастает, оно превращается в ключевой инструмент для поддержки и ускорения процессов, связанных с обработкой заказов. Помимо большой функциональности, которой обладают ERP-системы, они к тому же ассоциируются с развитыми технологиями: клиент-серверной архитектурой, реляционными СУБД, операционными системами Unix и Windows NT.
Нередко стандарты, являясь фиксацией определенной ступени развития, одновременно становятся и тормозом развития. Чтобы этого не произошло, система стандартов должна постоянно совершенствоваться, вбирая в себя новые технологии, вновь накопленный опыт (к сожалению, наша система стандартов на определенном этапе, особенно после распада Союза, практически перестала развиваться). Американские же концепции демонстрируют свое развитие непрерывно. Сегодня в моде новые аббревиатуры - COMMS (управление производством, ориентированным на заказчика) и CSRP (планирование производства, ориентированного на заказчика; о нем мы подробно писали в PC Week/RE, № 45/97, с. 62). Это означает, что в системе, в частности, должны поддерживаться многие языки и валюты, прогноз должен быть гибким и разнообразным (по продукции, по клиентам и т. д.). Система должна моделировать и анализировать не только “что было”, но и “что есть” и “что будет” и даже подсказывать, какими путями быстрее добраться к желаемой цели. Известные системы Baan, R/3, Symix, Oracle Applications и т. п. активно движутся в эту сторону, интегрируя продукты третьих фирм - разработчиков соответствующих средств. (Подробнее с американскими концепциями в области автоматизации управления промышленными предприятиями можно познакомиться на Web-узле общества APICS: www.apics.org.)
А у нас?
Нынешние отечественные разработчики (мы имеем в виду, конечно, известные на рынке крупные коллективы, создающие ПО масштаба предприятия), как правило, пишут собственные внутренние стандарты, определяющие общую организацию работ, правила взаимодействия между подразделениями, требования к пользовательскому интерфейсу и т. п. В них описана файловая структура разрабатываемой системы, структура репозитория, механизм поддержки версий и другие важные вещи. У наиболее “продвинутых” команд есть формализованные технологии для составления технических заданий, тестирования, выполнения пуско-наладочных работ и всех остальных обязательных этапов, сопровождающих создание продукта и его движение к заказчику. Причем от сотрудников фирмы-разработчика требуется неукоснительное соблюдение прописанных правил (что совершенно естественно - иначе зачем их писать?). Составители упомянутых технологических документов сознаются, что при формулировании правил многие из них опирались на перечисленные выше отечественные ГОСТы, но все-таки видоизменяли их, а не применяли как есть. Нам удалось обнаружить только одну команду, не изобретавшую велосипед, а реально использующую ГОСТы 1989 - 1990 г г. - это подразделение программных разработок под руководством Евгения Веселова (IBS). Что же касается российских программных продуктов, в основу которых положены какие-либо отечественные экономические концепции (за исключением разве что бухгалтерских), формализующие взаимоотношения между объектами в цепочке производитель - продавец - покупатель, то таких пока на нашем рынке нет.
ГОСТ 34.201-89 определяет виды, комплектность и обозначение документов при создании АС (рассматриваются стадии: “Техническое задание”, “Эскизный проект”, “Технический проект”, “Рабочая документация”, “Ввод в действие”).
ГОСТ 34.602-89 устанавливает состав, содержание и правила оформления документа “Техническое задание на создание (развитие или модернизацию) системы”.
ГОСТ 34.601-90 определяет стадии и этапы создания АС (“Формирование требований и разработка концепции АС”, “Техническое задание”, “Эскизный проект”, “Технический проект”, “Рабочая документация”, “Ввод в действие”, “Сопровождение АС”)
ГОСТ 34.401-90 рассматривает периферийные технические средства автоматизированных систем дорожного движения.
ГОСТ 34.003-90 - термины и определения.
Поясняют и расширяют стандарты методические указания и рекомендации. Одна рекомендация, например Р 50-34.119-90, касается состава и структуры локальных вычислительных сетей, применяемых в автоматизированных системах проектирования и изготовления (АСПИ) и в автоматизированных учрежденческих информационных системах (АУИС).
Продолжение следует
Том 1. Часть 1 - см. PC Week/RE, № /97, с. 59. Том 1. Часть 2 - № /97, с. 60. Том 1. Часть 3 - № /97, c. 64. Том 1. Часть 4 - № /97, c. 47. Том 1. Часть 5 - № /97, c. 50. Том 1. Часть 6 - № /97, с. 56. Том 2. Часть 1 - № /98, с. 62
