Почему нельзя просто заменить зарубежную систему на российский аналог

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

Больше 20 лет я работаю в энергетике: сначала на АЭС в эксплуатации и контроле металла, затем в проектах информационных систем, в том числе в импортозамещении системы ТОиР. Разберу эту проблему на примерах из энергетики: сначала на пути обычного ремонта, затем на согласовании ремонтного графика АЭС с программой неразрушающего контроля.

Что скрывается за привычной функцией

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

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

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

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

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

Был и «живой интерфейс». Стоимость работ считали в сметной программе. Она выдаёт один выходной файл, а прежний модуль ТОиР принимал работы в других единицах измерения. Специалист вручную правил файл и приводил данные к нужному виду. Такие вещи не видны в списке функций. Их находишь, только когда проходишь путь одной работы целиком.

Переносить всю старую логику тоже не нужно

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

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

Как появляются информационные острова

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

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

Два плана на одном оборудовании

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

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

При этом детализация ТОиР — это единицы оборудования. Трубопроводы там, как правило, мало кого интересуют: по сути это связи между установками. Но параметры среды в них такие, что во время работы находиться рядом персоналу запрещено или сильно ограничено. Вспомним АЭС «Михама» в Японии: в августе 2004 года на третьем энергоблоке разорвался трубопровод, погибли пять рабочих. Этот участок не проверяли 27 лет. Для контроля металла любой трубопровод — полноценный объект со своими элементами и историей , и его тоже нужно увязать с графиком ТОиР, где такого объекта может просто не быть. Вручную, по таблицам, такая сверка занимает много времени, и что-то легко упустить.

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

Работая в эксплуатирующей организации, я сталкивался с тем, что графики ТОиР и НК синхронизированы не полностью. Однажды ремонтное окно не совпало с потребностями контроля, и на основном оборудовании контроль по периодичности не удалось выполнить в полном объёме. Пришлось разбираться, что именно не сделано, включать эти позиции в следующую программу контроля с учётом выявленных разрывов и выполнять её в ближайший плановый останов. Справились, потому что специалисты были опытные и хорошо знали оборудование. Люди здесь — самый ценный ресурс. Но при сотнях тысяч элементов полагаться только на их опыт и память нельзя: если такой разрыв вовремя не увидеть, можно попасть в зону риска.

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

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

Коротко это взаимодействие можно представить так:

Что из этого следует для интеграции

Этот случай — прежде всего пример согласования производственных процессов. Для импортозамещения он важен тем, что показывает зависимость, которую легко пропустить при замене системы. Представим, что в требованиях указана передача графика ТОиР в систему контроля. Разработчики реализовали импорт: оборудование найдено, виды ремонта распознаны, даты загружены. С технической точки зрения обмен работает. Но позволяет ли это спланировать контроль? Чтобы ответить, придётся выяснить:

• как единица оборудования из графика ремонта связана с конкретными элементами металла и пунктами программы контроля;

• какие условия проведения работ можно определить по виду ремонта, а какие нужно уточнять;

• как специалисты фиксируют ограничения и передают предложения ремонтным подразделениям;

• как отражаются предложенные сроки и результат их согласования;

• что нужно повторно проверить после изменения графика.

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

Что значит «проработать требование ТЗ»

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

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

Результат такого анализа удобно свести в перечень вопросов, по которым стороны принимают решения. Для примера с ТОиР и НК он может выглядеть так:

Так становится понятнее и сама производственная задача, и границы ответственности участников проекта.

Проверять нужно весь рабочий маршрут

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

1. В систему поступает график ремонта.

2. Специалист сопоставляет его с потребностями контроля.

3. Обнаруживается ограничение по срокам или доступу.

4. Подготавливается предложение об изменении условий.

5. Ремонтное подразделение согласует решение.

6. График изменяется.

7. Специалист проверяет, позволяет ли новая версия выполнить необходимые работы.

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

Что считать результатом замены

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

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

А с какими проблемами вы сталкивались при внедрении новых решений? Делитесь в комментариях — будет интересно пополнить свой багаж знаний.