АСУ ТОиР — это инструмент, который должен позволить качественно планировать, получать и накапливать достоверную информацию, помогать принимать управленческие решения. Рассмотрен опыт, полученный при реализации проекта.
«Человеческий фактор» — это самая сложная часть в нашей программе АСУ ТОиР, которая тяжело идет и тяжело внедряется. Внедрением мы занимались с 2008 года. Результаты внедрения неоднозначны. Есть примеры плохие и хорошие. Плохих пока больше, т.е. не плохих, а результатов, которые нас не устроили как проектную команду. Есть и хорошие результаты, причем это не зависит от проектной команды, а зависит от площадки, где идет реализация.
Где-то через год после начала проекта мы разбирали результаты внедрения на пилотном предприятии. Вначале мы ставили довольно амбициозные планы, мы хотели все — всю функциональность — все автоматизировать. Вот что получилось (таб. 1).
| Показатель | Значение |
| Количество цехов, где используется АСУ ТОиР, ед. | 11+3 |
| Количество записей базы данных оборудования, ед. | 45510 |
| Количество действительных пользователей, чел. | 172 |
| Количество автоматизированных бизнес-процессов, ед. | 15 |
| Время работы пользователей в системе за год, час | 7190 |
| Количество созданных запросов работ, шт. | 1450 |
| Количество созданных заказов-нарядов, шт. | 10790 |
Слева — это функциональность, которая была реализована в системе технически. Правая колонка — это то, чем реально пользуются пользователи через год. Практически ничем не пользуются, кроме самых простых вещей — это выпуск заказ-нарядов, перерегистрация заявок на ремонт и месячное планирование — формально оно есть. Но это не то, чего мы хотели. То есть формирование некоего месячного плана, который потом на 90 % не соответствует реальному выполнению, это не планирование. Формально процесс есть, практически — нет.
Мы рассмотрели опыт, у кого что получалось в мировой практике. По западной статистике, 80 % менеджеров компаний, где реализовывались ERP-проекты, считают эти проекты неуспешными. Т. е. внедрение таких сложных или тяжелых IT-продуктов всегда не оправдывает ожидания и надежды менеджеров.
Второе. Проект этот на 80 % был организационный, а на 20 % — специальный или ИТ-проект. То есть сама по себе разработка бизнес-процессов, настройка программного продукта и его инсталляция — это задача проектная, но не очень сложная, решаемая задача. Мы реализовали это везде. А вот вторая задача — чтобы люди сели и начали работать так, как мы хотели, — получилась действительно сложной и тяжело реализуемой. И в этом плане результатов, на которые мы рассчитывали, мы не получили. Даже тот проект, который мы считаем успешным по одному предприятию, там, где все работает, на сегодня требуемого качества планирования еще нет.
Если мы говорим, что АСУ ТОиР — это инструмент, который должен позволить качественно планировать, получать и накапливать достоверную информацию, помогать принимать управленческие решения, то этого мы не добились. Хотя, с другой стороны, опять же обращаясь к опыту западных компаний с опытом внедрения, оценивая, как они это делали и сколько времени занимает этот процесс, мы поняли, что ставили перед собой слишком амбициозные задачи, потому что у нас на внедрение год-полтора планово давалось, и у нас ни разу не было в процессе внедрения одно предприятие; минимум два, потом три плюс два, потом 11 сразу.
Мероприятия по направлению:
Мероприятия по направлению:
Мероприятия по направлению:
| Бизнес-процесс | Отчет | Адресат |
| Ведение классификаторов и справочников | Отчет об открытых заявках на изменение справочников | Менеджер корпоративного проекта |
| Ведение реестра систем, ТП и ЕО | Отчет о пустых и некорректно заполненных полях БДО (по ПТЦ). | ПТЦ, СП, РП* |
| Регистрация дефектов и отказов | Количество созданных запросов работ (по инициаторам работ). Количество невостребованных запросов работ (по старшим планировщикам) | РП, СП, РП |
| Регистрация параметров технического состояния и результатов диагностики | Отчет о работе в АСУ ТОиР планировщиков ОТНУН (запросы работ, закрытые ЗН, запланированные ЗН) | Планировщик ОТНУН, РП |
| Регистрация наработки оборудования | Оборудование без регистрации наработки за период | ПТЦ, РП |
| Месячное планирование работ по ТОиР | Отчет о работе планировщиков в АСУ ТОиР (время работы; закрытые ЗН, трудочасы, ТМЦ; запланированные ЗН, трудочасы, ТМЦ) | СП, РП |
| Учет выполненных работ по ТОиР | Динамика статусов заказ-нарядов. Заказы, не выполненные согласно плану, по старшим планировщикам | Холдинг, топ-менеджеры, РП, СП |
Мероприятия по направлению:
Четкое описание механизма технической поддержки позволяет организовать взаимодействие пользователей и функционального администратора системы на высоком уровне и сделать работу пользователей более эффективной.
Мероприятия по направлению:
Основная идея — минимизация ручного труда, переход от бумажных документов к электронным.
Мероприятия по направлению:
В общем, в такие сроки и так быстро результат ни у кого не получался, да никто и не планировал. Первый этап — это просто работа и набор статистики в системе, и этот период занимает от начала внедрения два года. Нормальное планирование только на третий год. Происходят и изменения в связи с тем, что меняются сами предприятия. Если мы начинали с того, что практически весь персонал был собственный, и мы полагали, что важной и существенной частью будет управление с помощью АСУ ТОиР собственным ремонтным персоналом, его эффективностью, загрузкой, блокировкой ресурсов, то сейчас у предприятия этого ресурса нет, а есть только подрядчики. И получается, что бизнес-процессы, которые мы автоматизировали изначально, на сегодняшний момент претерпевают изменения.
Сами решения и реализуемые процессы также развивались, потому что с начала внедрения идет уже пятый год. Платформа одна, но понимание изменилось, и поэтому первая инсталляция и последняя — это «две большие разницы». Теперь мы пришли к необходимости процесса обратного, с последних наработок, где у нас достаточно хорошо получилось, теперь необходимо вернуться к первым и поднять до нужного уровня.
| Показатель | II полугодие 2010 | I полугодие 2011 |
| Время работы пользователей в системе, час | 1507 | 3595 |
| Количество созданных ЗН, шт. | 2602 | 5395 |
| Количество созданных запросов, шт. | 379 | 725 |
Основная проблема, почему не все получилось, — это, наверное, то, что мы недостаточное внимание уделили на пилотах проблеме интеграции с учетной системой. То есть у EAM-системы нет финансового модуля. Мы полагали, что эту интеграцию предприятие сделает самостоятельно, а мы сделали частично со стороны АСУ ТОиР, но бухгалтеры у нас люди передовые, самые главные на заводе, и они решили, что не надо. Т. е. по сути интеграции сделано не было. И люди были вынуждены работать в двух системах. Причем если учетная система — это обязательно, потому что там материалы, списания и деньги, то есть там не работать нельзя, то в этой системе, если не работаешь, то, возможно, кроме административных последствий от своих руководителей, ты ничего не понесешь. Но в итоге мы поняли, что если не получается сделать полноценную интеграцию, то лучше не делать вообще.
| № | Этап | Сроки | Результат |
| 1 | Создание базы данных оборудования (БДО) | 10.2006 — 06.2007 | Создана БДО (40000 единиц) |
| 2 | Подготовка в холдинге | 07.2007 — 12.2007 | Получен бюджет проекта, заключены договоры с подрядчиками, разработаны концептуальные документы |
| 3 | Подготовительные работы на предприятии | 01.2008 — 05.2008 | Создана сетевая инфраструктура, оборудованы рабочие места, обучены пользователи |
| 4 | Внедрение (проектная часть) | 06.2008 — 12.2009 | Разработаны проектные документы, регламенты, инструкции; настроены логика и интерфейс системы; обкатаны бизнес-процессы |
| 5 | Опытная эксплуатация | 01.2010 — наст. вр | Реализация интеграционных решений, переход к электронному документообороту |
Я намеренно говорю о том, что тяжело или неудачно получается при реализации проекта. В чем была стратегическая ошибка? Почему в пилотном проекте у нас получился результат хуже, чем на последующем внедрении?
Первая ошибка — при внедрении продукта нужно брать на себя внедрение и сразу интеграцию. А это тащит за собой те процессы, которые мы считали близкостоящими, но не нашими: это склады, закупки и снабжение, и нам пришлось серьезно заниматься в дальнейшем этими бизнес-процессами, их изменением. Обеспечивающая интеграция касается в основном учетных средств, и нам пришлось туда влезть, хотя изначально не планировали, считали, что это должны сделать другие люди на заводе. Но они не делают. Если мы хотим, чтобы это работало, приходится делать нам. При запуске интегрированной системы у пользователя уже нет возможности не работать в ней, потому что все завязано на получении материалов, на списании материалов, на закрытии месяца бухгалтерской и финансовой службами, на бюджетировании — и просто нет возможности не работать, иначе «подвешивается» уже весь завод.
Это было основной ошибкой, но не единственной. Были факторы, которые (они, наверное, везде есть) объективно на нас влияют. Это непонимание и нежелание менеджмента предприятия, начиная от директора. Все получилось там, где проектом заинтересованно занимались на уровне заместителя и директора, которые чуть ли не ежедневно мониторили процесс. Там, где не занимались или по остаточному принципу, все было тяжело.
Второй важный фактор — это везде: недостаток или неудовлетворенность результатом внедрения, недостаток административного ресурса. Надо понимать, что входить нужно с мощным административным ресурсом, который будет давить года два, постоянно и ежедневно. Примерно после двух лет у людей приходит понимание: да, эта штука нам нужна и полезна, как же мы без нее работали? Первые два года нужно постоянное давление. Если его нет, команде очень сложно. Сам продукт был реализован, все настройки сделаны, система рабочая, но не было выхода, на который я рассчитывал.
Что касается выбора системы или ее разработки. Разрабатывать такие системы для себя, мне кажется, это неправильно. Можно как-то кастомизировать, но лучше пробовать готовые продукты. Во всяком случае, для нас, для холдинга, это удобнее. Если каждый завод будет что-то придумывать, нужно держать людей, которые будут изобретать и реализовывать программы, потом это будет на разных предприятиях по-разному. В этом нет смысла. Нужно покупать качественные продукты и при необходимости кастомизировать. И сейчас то, что мы купили, используем процентов на 50. IT-стратегия холдинга появилась и утверждается только сейчас. Поэтому все площадки имели на тот момент разные IT-платформы учетных систем — как хотели, как понимали, исходя из тех средств, которые могли выделить. Это была еще одна серьезная сложность проекта, когда невозможно было сделать единое решение в части интеграции, которое можно было бы применять везде. Сейчас в части учетной системы практически все перешли на «1С. 8.2», все предприятия и интеграционные решения, которые сейчас делаются, — на единой платформе с одними бизнес-процессами.
Карамин Вадим, менеджер корпоративного проекта ОАО «Сибур-Нефтехим»
Журнал Prostoev.NET № 2(11), 2017
This website uses cookies.