Исходя из своего большого опыта внедрения подобного рода систем решил написать такую "простенькую" статью о том, что может пойти не так, как надо, при внедрении сложных информационных систем.
Еще раз, статья написана в обывательском стиле и основана на своем собственном опыте. Безусловно есть большое количество стандартов управления рисками проекта, и, по-хорошему, риски правильно описывать и управлять по стандартам проектного планирования.
Для предприятий, столкнувшихся с необходимостью внедрения PLM советую изучить стандарт PMBOK 7.0. Там описано все, что нужно. Могу даже поделиться шаблонами документов это стандарта. К сожалению, стандарт 7.0 не нашел в открытом доступе, но 6.0 можно почитать тут. Основной тезис, который говорю всем: успех проекта внедрения обеспечивается на самом первом этапе.
Если вначале не проработать все проблемы и риски- дальше их купировать на живом проекте крайне проблематично.
Для начала разделю эти проблемы на два лагеря: проблемы на этапе интеграции и проблемы на этапе опытно-промышленной эксплуатации. Дальше расскажу о проблемах, с которыми сталкивался именно я. На самом деле, их может быть на порядок больше.
Проблемы на этапе внедрения:
1. Нет явных технических или иных требований со стороны заказчика.
Внедрение решения из логики "потому что надо" или "на соседнем предприятии работает", к сожалению, обречено на провал. Поставьте себе цели, какие проблемы и задачи Вы хотите решить за счет внедряемого решения. Исходя из общих требований распишите требования на рабочие места пользователей.
2. Недостаточная погруженность архитектора и аналитика информационной системы в проблемы и задачи предприятия.
Несмотря на кажущуюся типичность проектов PLM- каждое предприятие уникально. Вместо того, чтобы оценивать и учитывать эти особенности, многие рисуют типовые структуры и внедряют типовые решения, не подходящие предприятию. (Хотя иногда и стандартные конфигурации могут подойти ).
3. Оплата за выполненные часы, а не результат.
Проблема возникает при найме интегратора с почасовой оплатой. Таких интеграторов много. В дальнейшем интегратор просто раздувает человекочасы, а результатов так и нет.
PS: Идея оплаты за часы отлично работает, когда в готовом проекте надо что-то изменить. Или же надо разработать небольшой плагин. Или постпроектная техническая поддержка, привязанная к человекочасам.
В любом случае, старайтесь указывать в договоре внедрения конкретные результаты, а не часы.
4. Слишком сложный технический проект с неявными результатами
Когда в проекте внедрения участвует интегратор, на первом этапе его участия обычно пишется технический проект или уточненное техническое задание.
Бывают случаи, что в порыве страсти архитектор настолько усложняет и размывает описание этого документа, что понять, как будет выглядеть модель потоков данных- невозможно.
Аналогичная ситуация может возникнуть и когда сам заказчик пишет сложное ТЗ, не понимая особенностей продукта или самого процесса.
Выхода два: упрощать или глубоко вникать в каждое предложение технического проекта. Как я сказал, успех будущего проекта закладывается на этом этапе.
5. Недостаточное планирование
Крайне важно прописывать время выполнения каждого этапа и реагировать на изменение временных этапов. Основная забота тут падает на руководителя проекта, который на селекторных совещаниях должен докладывать, все ли идет по намеченному плану, и как реагировать на различные отклонения от времени.
6. Решение не удовлетворяет потребностей заказчика
Очень часто систему Вам продает менеджер и обещает, что система может все (это не так:) ). Заказчик радуется и покупает систему, уверенно потирая руки.
Далее уже идет планирование внедрения и вдруг выясняется, что не все задачи могут быть решены этой системой, и еще хуже, если доработка также невозможна.
Советов несколько.
1. Перед покупкой решения Вы должны четко понимать, какие цели преследуете, чтобы за них спросить с продавца.
2. При показе решения заказчику должен участвовать не только менеджер но и технический специалист, который уже внедрял конкретный предлагаем продукт.
3. Перед покупкой решения выполните с интегратором пилотный проект. Это позволит оценить базовый функционал системы и ее возможности.
7. Нет выделенных сотрудников: руководитель проекта, функциональные заказчики/ размытая ответственность
У любого проекта со стороны заказчика должны быть ответственные люди, которые решают разные возникающие ситуации на проекте. Обычно эту ответственность прописывает руководитель проекта и закрепляет в Уставе проекта, либо в самом техническом проекте.
Крайне важно выделить функциональных потребителей системы, кто будет принимать настроенную систему от интегратора. Это должны быть люди, которые в этой системе будут работать руками.
По своему опыту могу сказать, что мы отказываем предприятиям в проектах внедрения, если не назначены подобные роли.
8. Загруженность сотрудников, занятых на проекте
Специалистам заказчика крайне важно выделить время, чтобы они могли участвовать в проекте внедрения.
9. Сопротивление сотрудников
Любая система приводит к прозрачности и порядку. А также часто усложняет работу сотруднику, который, допустим, привык любые изменение в чертеже проводить с помощью штриха и черной ручки. Естественно, сотрудник не будет рад любой системе, которая запрещает ему так делать.
Перед внедрением всегда нужно понимать, доросла ли ваша организация до такого уровня автоматизации или нет.
10. Отсутствие IT-инфраструктуры/системного администратора
Один раз мы участвовали в проекте, где сервер был развернут на машине администратора (такое тоже бывает). Больше мы такого не делаем :)
Иногда было, что сеть предприятия попросту не готова к тому объему передаваемых данных, и процесс сохранения конструкторских данных в PLM занимал часы. Естественно, что любой пользователь не согласится ждать такое время сохранения небольшого изделия
Обязательно перед внедрением системы ознакомьтесь с рекомендуемыми требованиями к серверу, сети и сопутствующему необходимому программному обеспечению.
К примеру, Вы прочитали, что серверная часть PLM требует 32 ГБ оперативной памяти. И радостные купили сервер с соответствующими показателями, но не учли дополнительные требования к СУБД или самой операционной системы.
Вторая проблема, которая встречается гораздо чаще- нет выделенного сетевого администратора.
11. Отсутствие регламентов работы/ нет выстроенных процессов
Самая сложная проблема, когда у предприятия не выстроена никакая методология работы. Люди управляют хаосом. Директор, в порыве очередной проблемы, пытается купить и внедрить систему, думая что она поможет решить проблемы.
Но нет, система только усугубит клубок этих проблем, потому что управлять хаосом в информационных системах в разы сложнее)
12. Нет условий для обучения
Также частая проблема, когда в порыве экономии арендных площадей все специалисты сидят друг на друге. Процесс обучения становится проблематичным.
Выходом конечно может послужить обучение через каналы связи, но тогда пользователей крайне важно обеспечить наушниками и вторым монитором, в котором будут дублироваться обучение преподавателя. Минус удаленного обучения- это отсутствие обратной связи от обучающихся. И тут гарантий качественного обучения никто дать не может.
Проблемы на этапе эксплуатации:
1. Нет выстроенного корпоративного университета
Процесс масштабирования настроенной системы и поддержания ее на плаву- важная задача. После ухода интегратора возникает вопрос, как обучать остальных или как найти информацию по определенным вопросам. Очень часто это просто ложиться на плечи администраторов PLM, но в масштабах большого предприятия вал вопросов завалит этого специалиста. Решение: внедрять систему, где будут храниться записи видеоуроков для специалистов разных направлений и различные узкие вопросы от специалистов и методы их решения.
2. Большое количество одновременных проектов внедрения без связи друг с другом
Если Вы собираетесь грамотно подходить к цифровизации своей организации и внедрять PLM, MES, MDM, BI, APS системы вместе- обязательно выделить архитектора проекта или заказать такой проект прежде, чем заниматься кусочным кустарным внедрением.
3. Нет выделенных администраторов PLM системы
Самая частая проблема, когда просто нет выделенного специалиста, и поддержкой системы будет заниматься сетевой администратор, который не имеет предметных знаний.
Если хотите успешный проект- выделите отдельного специалиста на поддержку. Хотя бы на первые полгода.
4. Нет специалиста, кто будет заниматься базой НСИ
Главная проблема полного внедрения PLM на предприятии- отсутствие необходимой базы нормативно-справочной информации: база материалов, стандартных элементов, операций, переходов, оборудования и т.д. Даже мы при внедрении обычно не касаемся вопросов полного насыщения базы. Именно поэтому, обязательно выделите человека, кто будет этим заниматься.
Что могу сказать по итогам. Внедрение PLM- это не вопрос обычного обучения специалистов, а многофакторной сложный процесс. Если Вы понимаете, что где-то еще не готовы- не форсируйте процессы внедрения, а предварительно подготовьтесь. Ведь Всем нужен результат, а не купленный софт и потраченные деньги.
Для связи используйте контакты,
Газизулин Александр
Telegram-канал для пользователей IPS
8-800-3333-205
gam@amcad.ru
