Управление проектами внедрения 1С:ERP

0. 691 29.05.18 09:55 Сейчас в теме
Тема статьи - «Управление проектами автоматизации 1С:ERP». В этой фразе хотелось бы поставить ударение на 1С:ERP. Почему?
- Потому что 1С:ERP – это достаточно сложный комплексный продукт.
- Проекты, которые мы делаем, зачастую охватывают все отделы и службы предприятия.
- Здесь, в отличие от того же УПП, требования немного меняются – речь идет уже не об учете, а о планировании, об управлении ресурсами, что само по себе является более сложной темой.
Об этом я и постараюсь рассказать.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Steelvan 95 22.06.18 11:06 Сейчас в теме
пресейл = предпродажа, дальше просто перестал читать и поставил минус
Designer1C; kadild; +2 2 Ответить
2. user774630 22.06.18 11:51 Сейчас в теме
(1) а как вы infostart в браузере набираете? Не корёжит?
DenisF8; andironenko; +2 1 Ответить
4. Steelvan 95 23.06.18 17:35 Сейчас в теме
(2) Вы путаете теплое с зеленым.

Для англицизма "пресейл" есть куда более русское слово "предпродажа".

Использование англицизмов называется "Превращение великого и могучего в русско-английский суржик".
Если вам сложно это понять на текущем уровне вашего развития, то попробуйте вернуться к этому через несколько годиков (предложение актуально, если вам до 30).
Designer1C; kadild; Yakud3a; +3 2 Ответить
5. andironenko 691 23.06.18 19:00 Сейчас в теме
(4) а что это за хрень у вас в нике "steelvan"?
PowerBoy; +1 Ответить
10. shuhard 24.06.18 10:35 Сейчас в теме
(4)
Использование англицизмов называется "Превращение великого и могучего в русско-английский суржик".

абсурдность данного утверждения в топике по 1С:ERP самоочевидна
7. andironenko 691 23.06.18 19:06 Сейчас в теме
3. genayo 22.06.18 11:58 Сейчас в теме
А кто выполняет роль аналитиков? Консультанты?
6. andironenko 691 23.06.18 19:05 Сейчас в теме
(3) у нас нет специально выделенных аналитиков. Это может быть консультант, может быть архитектор, может быть РП. По сути задача аналитика - это собрать требования, интерпретировать их должным образом и наложить на функциональную модель конфигурации, которая внедряется. Тут все зависит от того у кого есть компетенции в предмете - тот и становится аналитиком.
8. genayo 23.06.18 19:11 Сейчас в теме
(6) Если консультант не имеет навыков аналитика, то он может не увидеть в процессе внедрения/опытной эксплуатации узких мест и возможных улучшений, ведь невозможно все предусмотреть на 100% на этапе сбора требований.
9. andironenko 691 23.06.18 19:20 Сейчас в теме
(8) такая проблема есть, но мы её сейчас решаем не за счёт выделения аналитиков, а за счёт общего повышения квалификации персонала - внутри Раздолья появилась своя бизнес-школа - один из курсов из нее, я, кстати, недавно читал в учебном центре #1 1С - автоматизация пищевки на 1С:ERP. Таких курсов несколько, количество расширяется.
Мы сделали ставку на знание отраслевой специфики - то есть не какие-то общие принципы анализа, а понимание того как что работает в подобном предприятии - что можно делать, а что нет. Тогда люди имеют уже набор готовых шаблонных решени и просто сверяют из с конкретной ситуацией.
11. gendal 3 27.06.18 23:39 Сейчас в теме
"Очень многие консультанты «болеют» следующим – они говорят, что «пользователи дураки"...

Что это за быдловатые консультанты у вас? Если "консультант" не умеет общаться с людьми - завалит все дело. На этапе внедрения, особенно если работала другая система ранее, которая "вылизана" и под любой чих пользователя есть отчет, работа в новой системе вызывает сравнение и сопротивление. Какие-то вещи банально не удобно реализованы и пользователи отказываются так работать. Тут нужно быть дипломатом, тупым продавливанием ничего не выйдет. А любое серьезное внедрение - это десятки тысяч сказанных слов и человеко-часов плотного общения с пользователями.
12. andironenko 691 01.07.18 11:46 Сейчас в теме
(11) Ну прям вот "дураки" никто конечно не говорит - но достаточно часто присутствует определенное ложное чувство собственного превосходства над пользователем. Которое ведет консультанта по неправильной дороге и приводит к конфликтам.
13. kuril 57 31.07.18 13:41 Сейчас в теме
Хороший и объемный материал, Андрей! Спасибо

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

Есть методика разработки и внедрения информационных систем - ГОСТ 34
Если соединить все - предпродажу -> проект -> дальнейшие продажи
то я бы описал это следующим образом:

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

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

2. Самое лучшее что я видел по ведению (не мелких) проектов ГОСТ 34 - там есть все
0) устав проекта - на мой взгляд - нужно на очень крупных (over 10000 человек) предприятиях при тотальных проектах. меньше - мертвый документ.
а) приказ о рабочей группе
б) тех.требования + подпись
в) эскизный проект - как можно скорее - это такой MVP будущей системы.
г) программа и методика испытаний (ПМИ) + подпись
д) программа обучения->приказ об обучении->обучение -> акт
е) тестовая эксплуатация (ТЭ) -> доработка (scrum)
ж) опытная эксплуатация (ОЭ) -> приемка -> доработка (scrum) ->Акт
з) промышленная эксплуатация (ПЭ) -> акт

Еще очень классная штука - протокол совещаний - после каждой встречи - перекладывать на стандартный протокол цель и результат встречи - рассылаем всем участникам и исполнителям - очень координирует/дисциплинирует крупные проекты.

Считаю самым важным именно первый пункт - быть специалистом лучшим, чем заказчик - он покупает именно вашу компетенцию и ответственность.

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

Думаю, если так подходить - то повторные заказы - дело времени.
Удачи на проектах
Designer1C; +1 Ответить
14. 1cNike 210 02.08.18 00:53 Сейчас в теме
(13) По поводу устава согласен. Обычно его делаю, и за весь ход проекта о нем вспоминают обе стороны от силы несколько раз. Протоколы лучше вести для каждой рабочей встречи. Даже если консультант просто поговорил с сотрудникам Заказчика, но при этом были приняты какие-то влияющие решения - лучше их зафиксировать под подпись.
К документам я бы еще добавил справку о статусе проекта. Краткая выжимка о текущем состоянии проекта - где находимся, что делаем, открытые вопросы, текущие риски и принятые/принимаемые по ним меры и т.п. На начальном/завершающем этапах проектов справку делаю не реже раза в неделю (обычно к совещанию по статусу проекта). В середине проекта раз в две недели/месяц.
17. skillman 1 30.11.20 03:43 Сейчас в теме
(13) Можете поделиться примерами документов к проектам?
15. 1cNike 210 02.08.18 01:20 Сейчас в теме
(0) Спасибо за статью, почерпнул для себя кое-что новое.
По поводу бюрократии и экономии времени при согласовании и подписании документов. Добавлю свой вариант, который использовал/использую на проектах для быстрого и упрощенного процесса подписания протоколов совещаний по статусу проекта. Раньше на некоторых проектах испытывал затруднения в получении подписи под "судьбоносными" протоколами на которых принимаются важные решения и т.п. Тратил на это какое-то время, т.к. никто не хочет подписывать такой документ первым, особенно если в проекте много политики. Приходится разными способами искать "слабое звено", которое подпишет протокол первым. :)
Теперь я добавляю в Устав строчку с обязанностью РП со стороны Заказчика в ознакомлении и согласовании принятых решений в проектных документах всеми участниками проектной группы со стороны Заказчика. Участники для ознакомления перечисляются в протоколе. Таким образом получив подпись РП со стороны Заказчика под протоколом я автоматически получаю согласование и всех перечисленных участников со стороны Заказчика. Договорится с одним человеком (РП) зачастую проще, чем с пятнадцатью. Участники проектной группы Заказчика зная эту особенность взаимодействия начинают активнее общаться со своим РП и решать внутренние вопросы по решениям перечисленным в протоколе практически без моего участия. Остается немного подождать и получить подпись, либо обоснованные изменения по принятым решениям.
kuril; kalyaka; Designer1C; +3 Ответить
16. kuril 57 06.08.18 15:50 Сейчас в теме
(15)

Теперь я добавляю в Устав строчку с обязанностью РП со стороны Заказчика в ознакомлении и согласовании принятых решений в проектных документах всеми участниками проектной группы со стороны Заказчика.


благодарю, попробуем
18. skillman 1 30.11.20 03:45 Сейчас в теме
Андрей, было полезным прикрепить примеры документов с проектов, которые вы считаете лучшим и успешным.
Устав, функциональную модель, приказ о назначении раб группы.
Естественно конфиденциальная информация меня не интересует, а вот посмотреть применение good practics хотел бы увидеть
Night_Trap; +1 Ответить
Оставьте свое сообщение
Вопросы с вознаграждением