Особенности внедрения ERP-системы на энергетическом предприятии

Отраслевая научно-техническая конференция «Проблемы автоматизации и внедрения информационных технологий на предприятиях ЯОК и атомной энергетики»

Предыстория

Краткая характеристика Энергоуправления РФЯЦ-ВНИИЭФ

ФГУПД «Обеспечение РФЯЦ-ВНИИЭФ» (ранее – «Энергоуправление РФЯЦ-ВНИИЭФ») представляет собой сложный производственный комплекс с несколькими видами деятельности:

• производство и отпуск электро- и теплоэнергии;
• подъем и отпуск артезианской воды из скважин;
• снабжение потребителей природным и сжиженным газом;
• услуги местной, междугородней и международной телефонной связи;
• телеграфные услуги.

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

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

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

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

Результаты аудита

Аудиторы из фирмы Русаудит обследовали предприятие и подытожили:

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

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

Курс – внедрение ERP-системы

Для устранения недостатков руководство предприятия решило внедрять ERP-систему, управляющую ресурсами предприятия в и краткосрочном, и в среднесрочном временных промежутках.

Выбор пал на продукт Microsoft Axapta и на НТО «Терси» как на внедренца и сертифицированного партнера фирмы Microsoft.

При внедрении ERP-системы ставились цели:

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

Проблемы разработки и внедрения АСУП на энергетических предприятиях отрасли

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

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

Каждую из проблем обсудим ниже на примере «Энергоуправления РФЯЦ-ВНИИЭФ».

Наслоение «эпох»

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

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

Действующая на предприятии фрагментированная АСУП

Ручное преобразование показано кружком на изломе стрелки.

Рис. 1

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

Действующий на предприятии процесс по мониторингу бюджета

Диаграмма IDEF0. Все счета регистрируются дважды в программных системах ХХХ и YYY.

Рис. 2

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

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

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

Наблюдательная роль первых лиц

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

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

Сложность учета

Действующий учет в «Энергоуправлении РФЯЦ-ВНИИЭФ» ведется по бухгалтерским, сметным и бюджетным категориям.

Бухгалтерский учет ведется по стандартным синтетическим счетам, их около полусотни, и по аналитическим категориям, их 7:

• подразделение – 8 единиц;
• вид направления прибыли (реконструкция, автоматизация и т. п.) – 8 статей;
• статьи затрат (топливо, запчасти, зарплата основных рабочих и т. п.) – 160 статей;
• вид продукции (электроэнергия низкого напряжения, пар высокого давления и т. п.) – 62 статьи;
• цели затрат (текущий ремонт оборудования, капитальный ремонт зданий и т. п.) – 10 статей;
• группы сырья и материалов (сырьё, тара, стройматериалы и т. п.) – 8 статей;
• виды заработных плат (основная и дополнительная) – 2 статьи.

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

Бюджетное и сметное планирование ведется на предприятии по следующим основным категориям:

• подразделение; совпадает с бухгалтерским учетом;
• вид направления прибыли; совпадает с бухгалтерским учетом;
• вид продукции – 7 статей; совпадают только основные виды продукции;
• статья затрат, связанные с целями затрат (топливо на технологические цели, топливо на пусконаладку и т. п.) – примерно 390 статей; нет совпадений с бухучетом;
• группа сырья и материалов, связанная с целями затрат (стройматериалы на текущий ремонт зданий, стройматериалы на капитальный ремонт зданий и т. п.); нет совпадения с бухучетом;
• вид зарплаты, связанный с целями затрат и с принадлежностью работников к основным, вспомогательным цехам или к АУП (зарплата основных рабочих, зарплата ремонтников на капитальный ремонт зданий и т. п.) – около 50 видов; нет совпадения с бухучетом.

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

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

Действующая схема ручной переклассификации учетных статей

Листками «Перекодирование» обозначены ручные операции по переводу учетной статьи из одной классификационной системы в другую.

Рис. 3

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

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

Сложности в постановке задач

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

Предпроектное обследование проводится в несколько перекрывающихся и повторяющихся этапов, а если упрощенно, – то в четыре этапа:

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

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

Таким образом, на каждом этапе предпроектного обследования происходит искажение целей и задач автоматизации, обусловленное природой человеческого мозга, иллюстрацией чему служит этот рисунок (Рис. 4).

Искажение постановочной задачи на этапах предпроектного обследования

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

Рис. 4

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

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

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

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

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

«Мертвое время» ошибки при внедрении скелетной ERP-системы

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

Рис. 5

Чем дольше ошибка проживет незамеченной, тем больше усилий понадобится, чтобы её устранить. Заложенные в техзадание содержательные ошибки выявятся только накануне или в ходе приемо-сдаточных испытаний. Тогда, чтобы исправить постановочную ошибку, придется переделывать весь проект: перепроектировать, перепрограммировать, повторно отлаживать и испытывать.

Решение проблем

Сложность учета

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

Анализ имеющихся бюджетных статей, выявление их зависимостей и повторения позволил выделить среди них несколько независимых категорий: практически все статьи образованы как различные сочетания сметных статей, целей затрат и видов затрат. Например, бюджетную статью «Материалы на текущий ремонт зданий и сооружений» можно рассматривать как сочетание сметной статьи «Материалы», цели затрат «Текущий ремонт» и вида затрат «Цеховые затраты». Кроме того, некоторые бюджетные статьи частично совпадают с субсчетами в бухучете.

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

Преобразование нескольких классификационных систем в единую систему

Прежняя классификационная система – слева, суммарная действующая мощность её классификационных множеств равна 92 000 статей. Новая единая система – справа, в ней всего лишь 582 статьи.

Рис. 6

Суммарная номенклатура статей в прежней системе классификации равна 92 000, а в новой единой системе – всего лишь 582 статьям.

Наслоение «эпох»

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

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

Чтобы ликвидировать изолированные подсистемы в действующей АСУП, нужно заменить её единой современной ERP-системой (Рис. 7).

Современная ERP-система

ERP-система имеет модульный состав, но единое ядро.

Рис. 7

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

Новый процесс по мониторингу бюджета

Диаграмма IDEF0. Любой первичный документ регистрируются однократно.

Рис. 8

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

Трудности в постановке задач

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

В 1981, независимо друг от друга, Лаура Черер, системный аналитик, и Джеймс Мартин, известнейший ученый, обладатель Пулицеровской премии, по мнению журнала Computerworld один из четырех самых влиятельных людей в компьютерной индустрии, – оба пришли к общему пониманию: чтобы кардинально сократить количество концептуальных, содержательных, смысловых ошибок в спецификациях, нужно начинать не с них, а с макетирования программной системы.

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

Одной из ключевых публикаций на эту тему в России стала в 1993 книга Громова «Очерки информационной технологии»[4]. Громов наглядно, в виде схемы, показал тяжесть ошибок, возникающих на разных стадиях разработки, и назвал «мертвым временем» запаздывание в выявлении ошибок, неизбежное в каскадной схеме проектирования. Он выступил за макет программной системы, «тот самый макет, который веками сопровождал любую сколько-нибудь сложную инженерную разработку, а последние 100 лет не сходит со стола электро- и радиоинженеров.» .

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

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

Похожая картина в параллельном стандарте «Единая система программной документации. Стадии разработки»[7]. В нем тоже нет ни слова о макетах.

Эти умолчания удивительны хотя бы потому, что аналогичный стандарт в машиностроении «Единая система конструкторской документации. Стадии разработки»[8], принятый в еще 1968 году, предусматривает изготовление макетов и опытных образцов на каждой стадии проекта.

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

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

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

Итог

Проблемы автоматизации в управлении энергетическим предприятием разрешимы, если преобразования проводятся

• системно;
• внешней командой специалистов, обладающей методикой и инструментами внедрения;
• знающей предмет автоматизации и особенности атомной отрасли.