От чего статистика так печальна? Почему проекты валятся один за другим? Вот вам еще одна точка зрения на сей факт.4 ключевые проблемы проектов внедрения “1С:Предприятие”.
Итак. Проект завален. В чем причина?
Причин конечно можно назвать много. На кого не посмотри, явно на причину похож! И разбор полетов можно делать до посинения.
Ключевая проблема в том что внедрением занимаются программисты. Хотя это задача управленческая. Только человек с компетенциями руководителя, способен доводить действия до результатов, вне зависимости от затруднений.
Разбираем…
Для внедрения нужны 3 ключевые роли (моя версия):
- руководитель проекта (тот кто добьется результата, может привлекаться со стороны);
- программист (специалист знакомый с программой, и тем как выглядят процессы при ее использовании, может привлекаться со стороны);
- специалисты по текущим процессам (как правило, внутренние сотрудники, желательно поадекватней, хотя грамотный РП выудит нужную информацию даже из пьяного бабуина).
Для внедрения нужны 3 ключевые роли (версия В. Тарасова, (с) Управление по Макиавелли):
- Фанат – тот кто знает как выглядит конечный результат, и не боится вступать в конфликт, защищая идею, если кто-то решил, вводит противоречия в проект, пытается все вернуть на прежние места;
- Менеджер – тот, кто сумеет совместить старые порядки, с новыми, напишет инструкции;
- Крестный отец – тот, чья сила обеспечивает движение проекта, тот кто может применять административный ресурс.
В обоих вариантах роли подразумевают лишь роли. Они могут соответствовать одному человеку или нескольким. Важно чтобы они были.
Кроме людей понадобится компьютер, сама программа и листок бумаги.
Если убрать в сторонку толстые книги по PMI, PM BOK, Agile … Ключевые правила, нарушение которых приводит к провалу проекта. Правила очень простые. Но нарушаются в 99% случаев.
- Правило №1. Еженедельные совещание во главе с руководителем проекта (РП). Руководитель проекта задает вопросы, дает задания, с одной лишь целью… выполнить правило №2.
- Правило №2. По итогам каждого совещания нужно делать отчет о состоянии проекта, который потом рассылается всей группе. Отчет очень простой, да супер эффективный, состоит из 3х разделов. Результаты по итогам прошедшего период, План действий на ближайший период, Обнаруженные проблемы. Напротив каждого важного пункта, сроки и ответственные. Можно добавлять разделы еще, но это ключевые и обязательные. Они обновляются по итогам каждого совещания.
- Правило №3. Пользователям нужны инструкции. Но инструкции по процессам и функциям, а не объектам и документам программы, кои идут в комплекте. Отличие существенное и их рассмотрим ниже.
- Правило №4. Служба технической поддержки, способная решать сложные технические проблемы и находить решение ошибок. Может быть удаленная. Но надежная. Потому, если нет поблизости, можно купить кого-нибудь через Интернет.
А вот теперь подробней по каждому пункту.
- По правилу №1. РП это ключевая фигура. Можно нарушить любые правила и испортить все что угодно, но если РП достойный то он вырулит. Но если РП нет или вместо него Чучело, тогда на каждом совещании будем узнавать о том, что у нас снова что-то не так и сроки будут звучать «ну вот еще пару недель и все будет» или «да мы почти закончили, нужно только начать да кончить», или «не знаю сроков, тут много всяких нюансов», а может быть РП обвинит всех во всем, скажет, что все дураки, что в провале проекта виноват тот, тот или тот, а он сделал все что мог.
- По правилу №2. Отчет это ключ от двери, где деньги лежат. В разделе Результаты пишем что было сделано за прошлую неделю, и все те результаты которые достигнуты по ходу проекта. В разделе План пишем те действия, которые планируются, ответственные, сроки, на следующий период. В Проблемах пишем какие-то затруднения, которые приводят к пробуксовке, и ответственных. Это может быть сам РП, программист, пользователь, или служба технической поддержки. Отчет обновляется по итогам совещания. Рассылается проектной группе. И так до следующего совещания. На следующем садимся, проходимся по пунктам, срокам, ответственным. Если срок нарушен, то нужно сделать все возможное, чтобы человеку больше не захотелось нарушать данное им слово. В общем добиваемся того чтобы в следующий раз ставили или более реальные сроки или кровь из носу выполняли те что установили.
- По правилу №3. Программа это вторично. Запустить систему можно и без программы. А вот организовать процесс без инструкций это сынок фантастика. Инструкции это основа системы. Но инструкции не те что идут в комплекте с 1С Предприятие. С теми инструкциями можно идти костер разжигать. Пользователям от них толку мало, т.к. эти инструкции написаны программистами для программистов. Книги тоже дают мало пользы, особенно новичкам. Инструкция должна быть написана с точки зрения процессов и процедур. Полный порядок действий, от А до Я с картинками. Плюс условия, при которых процесс начинает ветвиться и вилять, все возможные петли. Мол если это тогда вот туда. Такие процессы идут с развитыми продуктами типа SAP, Navision, DIRECTUM, там где культура внедрения развита и есть соответствующая категория специалистов. А вот в 1С этой категории нет и соответственно знаний этих тоже. Есть программисты, которые не в курсе что такое инструкции для пользователей, что такое процессы, что такое ТЗ на внедрение. Они их путают с инструкциями по программе, а также с ТЗ на разработку, думая что это одно и тоже или что то похожее.
- По правилу №4. 90% организаций продающих или внедряющих 1С до сих пор относятся к тех.поддержке как к чему-то мало важному. Обращения пользователей остаются без регистрации, теряются, забываются, забиваются. Контроля сроков нет. Доверие пользователей теряем в первые же секунды сотрудничества.
Резюме
Не надо учить умные книги и залазить в дебри теорий. Это очень простые правила. Которые нужно лишь постараться выполнить. Я понимаю, что найти РП из п.1 в наше время сложнее, чем почесать ногой за ухом, но пойдет любой человек с организаторскими компетенциями, который сможет выполнить остальные 3 пункта.
Источник
