Спасибо за полезное видео! А можете показать примеры документов? Мы занимаемся внедрением CRM. Сейчас систематизирую структуру работ и шаблоны документов в проекте. В частности описываю этап анализа. Хочется сравнить с вашим опытом. Например, мы описываем бизнес-процессы в нотации BPMN, а вы как?
Спасибо, стараемся ) Могу прислать или показать примеры. Какие именно документы интересуют? Вообще все конечно не покажу - коммерческая тайна :) Но отдельные обезличенные от клиентской информации можно.
Проект начинается с инициации. С чьей-то идеи, потребности, озвученной в курилке, написанной на салфетке и т.п. Далее идет ряд важных шагов по формированию границ, этапов, стоимости, которые затем укладываются в приложения к договору/контракту. Описывается взаимодействие участников. Создается устав. Определяется набор проектных документов. Первичные встречи проводятся для определения всего этого добра. В общем, обширная работа. Видео начинается с этапа обследования, что, на мой взгляд, не совсем корректно, т.к. показывает не дорожную карту проекта, а дорожную карту некоторых из его этапов. И этап "Запуск" крайне непонятен. В данном случае больше похоже, что должно быть "Тестирование". Опытная или опытно промышленная эксплуатация. Только после приемочных испытаний можно сдавать систему в промышленную эксплуатацию и это уже больше соответствует заголовку "Запуск". Ну и я бы добавил этапы технической поддержки. Только по приведенным схемам непонятно куда их тут вставить. Обычно ТП подключается при ОЭ или ОПЭ.
Не первый десяток лет тружусь в сфере запуска (в хорошем смысле этого слова) проектов (и не только ИТ). Так и не научился на старте точно, да что там точно, иногда с точностью до раз, определять итоговую стоимость затрат по проекту. Не потому, что не понимаю ничего в этом (количество успешно выполненных внедрений говорит об обратном), а потому, что практически на каждом этапе основные задачи, а иногда и цели, проекта корректируются. Вы-же, как о само собой разумеющемся, мимоходом упоминаете "аванс получен". Для меня это означает согласование твёрдой сметы проекта и является единорогом. Вопрос (если Вас не затруднит): как Вы определяете размер аванса и стоимость проекта? Без подробностей. Подробности слишком персонифицированы. Просто методологию крупными мазками.
Сначала отмечу, у нас все же проекты хоть и различные, но все в одной сфере - автоматизации на 1С. Внутри еще остается очень много деталей, но границы установлены - это не построение инфраструктуры, не сети, не SAP, не e-commerce, то есть мы копим опыт внутри одной области, одной сферы, 1С внедрений. Дальше методика делится на 2 части - прослеживаемость границ и собственно оценка. Границы впервые появляются на этапе подготовки КП. Самое первое КП которое уходит заказчику уже содержит границы (у нас есть список видов границ и примеры того что может входить/не входить). Задача продавца на пресейле, не только ПРОДАТЬ проект клиенту, но и понять и четко зафиксировать границы. Когда мы обсуждаем с клиентом КП, мы проговариваем границы - вот смотрите, это входит. Это тоже. А это нет. И это нет. Все верно? Если выясняется что клиент границы представляет иначе, или вообще вспоминает что-то, о чем ранее не говорил, мы решаем можно ли оставить стоимость, или ее тоже надо пересмотреть. Границы очень детальные, это важно. Они делятся на организационные, технологические, функциональные, юридические, границы передачи знаний... Далее на каждом шаге мы эти границы проверяем и держим. После утвержденного КП - они попадают в устав. Далее в модель и требования на разработку. Мы возвращемся к ним когда обсуждаем план запуска и когда запускаем систему (и доказываем что запустили :)) Собственно оценка. Исходя из границ мы оцениваем стоимость обследования. У нас есть табличка, где собраны все возможные функции, и по каждой оценка - сколько нужно времени на подготовку, сколько на интервью, сколько на обработку результатов и оформление. + время на сбор цельного документа. Обследования всегда оценено точно (с учетом зафиксированных границ). Остальные этапы оценены диапазонами, чем понятнее для нас бизнес заказчика, чем он проще и прозрачнее, тем более узкий диапазон. Соответственно сделали обследование, уточнили стоимость следующего этапа. Сделали модель, уточнили стоимость следующего этапа. И так далее. Если нужны еще уточнения, пишите, буду рад ответить
@@cybrat50 Спасибо большое за обстоятельный ответ. Вопросы следующие: 1. Что такое в Вашей интерпретации аббревиатура "КП"? (в моей - "команда проекта", но в контексте она не подходит). 2. Сколько ресурсов потребовалось на составление системы нормирования? (ИМХО это - гигантский объём, сопоставимый с необходимым для формирования ЕРЕРов, требующего серьёзного госфинансирования). 3. Не все переговоры заканчиваются поступлением аванса. Как Вы оцениваете затраты на нереализованные подготовительные мероприятия в долях от доходности реализованных проектов? 4. 1С - огромная страна. На каких направлениях вы специализируетесь? Если возможно, с примером знаковых успешных внедрений. 5. Какова Ваша специализация в команде (PM, DBA, ...)? Понимаю, что ответы все вопросы, кроме первого и пятого, могут составлять коммерческую тайну. Потому заранее прошу прощения за слишком откровенные вопросы. Задаю их как с целью самообразования, так и с целью рассмотрения вариантов дальнейшего сотрудничества.
@@ГлебПластинин-ш3э Попробую ответить на все ) Мы не так систематизированы как хотелось бы, все таки мы относительно маленькие, и проекты у нас тоже не большие. Так что во многом мы полагаемся на здравый смысл и допущения. 1. КП - коммерческое предложение 2. Не очень много. У нас нет цели задать высокие стандарты для отрасли, мы знаем точно кто будет делать, мы понимаем что уже делали эти задачи, и сколько времени это заняло. Так что это просто эксель с множеством пунктов, с примерными оценками в часах. И конечно так мы получаем предварительную оценку, которую потом можем экспертно корректировать. Как в сторону "что-то много получилось, клиент то небольшой", так и в сторону "да ну, явно не учли сложность, на одно общение с руководством половина времени уйдет". То есть от человеческого фактора в оценке мы не избавились конечно. 3. до 5% максимум, в среднем до 3% уходит на пресейл 4. К сожалению, проектов масштаба "почта России" или РЖД (так чтобы прямо знаковые) нет. Мы одни из немногих, кто внедряет БиТ.Финанс (кроме 1бит), и делает это успешно. Предпочитаем делать проекты с большим бизнес-обследованием (улучшениями, управлением изменениями, и т.д.). Кейсы тут есть corada.ru/nash-opyt/ 5. я - гендир ) Но считаю что важно быть погруженным, так что далеко от проектного офиса и от наших клиентов не отхожу.
Спасибо большое за материал!
Первое видео, где все четко и понятно как и с чего начинать внедрение 1с.
Хорошее видео, благодаря вам расскажу об этом процессе в вузе)
Огонь!
Спасибо за полезное видео! А можете показать примеры документов? Мы занимаемся внедрением CRM. Сейчас систематизирую структуру работ и шаблоны документов в проекте. В частности описываю этап анализа. Хочется сравнить с вашим опытом. Например, мы описываем бизнес-процессы в нотации BPMN, а вы как?
Спасибо, стараемся )
Могу прислать или показать примеры. Какие именно документы интересуют? Вообще все конечно не покажу - коммерческая тайна :) Но отдельные обезличенные от клиентской информации можно.
@@cybrat50 можно например шаблон ФТ
@@yzyryanov1 Куда прислать? )
Проект начинается с инициации. С чьей-то идеи, потребности, озвученной в курилке, написанной на салфетке и т.п. Далее идет ряд важных шагов по формированию границ, этапов, стоимости, которые затем укладываются в приложения к договору/контракту. Описывается взаимодействие участников. Создается устав. Определяется набор проектных документов. Первичные встречи проводятся для определения всего этого добра. В общем, обширная работа. Видео начинается с этапа обследования, что, на мой взгляд, не совсем корректно, т.к. показывает не дорожную карту проекта, а дорожную карту некоторых из его этапов.
И этап "Запуск" крайне непонятен. В данном случае больше похоже, что должно быть "Тестирование". Опытная или опытно промышленная эксплуатация. Только после приемочных испытаний можно сдавать систему в промышленную эксплуатацию и это уже больше соответствует заголовку "Запуск".
Ну и я бы добавил этапы технической поддержки. Только по приведенным схемам непонятно куда их тут вставить. Обычно ТП подключается при ОЭ или ОПЭ.
Не первый десяток лет тружусь в сфере запуска (в хорошем смысле этого слова) проектов (и не только ИТ). Так и не научился на старте точно, да что там точно, иногда с точностью до раз, определять итоговую стоимость затрат по проекту. Не потому, что не понимаю ничего в этом (количество успешно выполненных внедрений говорит об обратном), а потому, что практически на каждом этапе основные задачи, а иногда и цели, проекта корректируются. Вы-же, как о само собой разумеющемся, мимоходом упоминаете "аванс получен". Для меня это означает согласование твёрдой сметы проекта и является единорогом.
Вопрос (если Вас не затруднит): как Вы определяете размер аванса и стоимость проекта? Без подробностей. Подробности слишком персонифицированы. Просто методологию крупными мазками.
Сначала отмечу, у нас все же проекты хоть и различные, но все в одной сфере - автоматизации на 1С. Внутри еще остается очень много деталей, но границы установлены - это не построение инфраструктуры, не сети, не SAP, не e-commerce, то есть мы копим опыт внутри одной области, одной сферы, 1С внедрений.
Дальше методика делится на 2 части - прослеживаемость границ и собственно оценка.
Границы впервые появляются на этапе подготовки КП. Самое первое КП которое уходит заказчику уже содержит границы (у нас есть список видов границ и примеры того что может входить/не входить). Задача продавца на пресейле, не только ПРОДАТЬ проект клиенту, но и понять и четко зафиксировать границы. Когда мы обсуждаем с клиентом КП, мы проговариваем границы - вот смотрите, это входит. Это тоже. А это нет. И это нет. Все верно? Если выясняется что клиент границы представляет иначе, или вообще вспоминает что-то, о чем ранее не говорил, мы решаем можно ли оставить стоимость, или ее тоже надо пересмотреть. Границы очень детальные, это важно. Они делятся на организационные, технологические, функциональные, юридические, границы передачи знаний...
Далее на каждом шаге мы эти границы проверяем и держим. После утвержденного КП - они попадают в устав. Далее в модель и требования на разработку. Мы возвращемся к ним когда обсуждаем план запуска и когда запускаем систему (и доказываем что запустили :))
Собственно оценка.
Исходя из границ мы оцениваем стоимость обследования. У нас есть табличка, где собраны все возможные функции, и по каждой оценка - сколько нужно времени на подготовку, сколько на интервью, сколько на обработку результатов и оформление. + время на сбор цельного документа. Обследования всегда оценено точно (с учетом зафиксированных границ).
Остальные этапы оценены диапазонами, чем понятнее для нас бизнес заказчика, чем он проще и прозрачнее, тем более узкий диапазон. Соответственно сделали обследование, уточнили стоимость следующего этапа. Сделали модель, уточнили стоимость следующего этапа. И так далее.
Если нужны еще уточнения, пишите, буду рад ответить
@@cybrat50
Спасибо большое за обстоятельный ответ.
Вопросы следующие:
1. Что такое в Вашей интерпретации аббревиатура "КП"? (в моей - "команда проекта", но в контексте она не подходит).
2. Сколько ресурсов потребовалось на составление системы нормирования? (ИМХО это - гигантский объём, сопоставимый с необходимым для формирования ЕРЕРов, требующего серьёзного госфинансирования).
3. Не все переговоры заканчиваются поступлением аванса. Как Вы оцениваете затраты на нереализованные подготовительные мероприятия в долях от доходности реализованных проектов?
4. 1С - огромная страна. На каких направлениях вы специализируетесь? Если возможно, с примером знаковых успешных внедрений.
5. Какова Ваша специализация в команде (PM, DBA, ...)?
Понимаю, что ответы все вопросы, кроме первого и пятого, могут составлять коммерческую тайну. Потому заранее прошу прощения за слишком откровенные вопросы. Задаю их как с целью самообразования, так и с целью рассмотрения вариантов дальнейшего сотрудничества.
@@ГлебПластинин-ш3э Попробую ответить на все ) Мы не так систематизированы как хотелось бы, все таки мы относительно маленькие, и проекты у нас тоже не большие. Так что во многом мы полагаемся на здравый смысл и допущения.
1. КП - коммерческое предложение
2. Не очень много. У нас нет цели задать высокие стандарты для отрасли, мы знаем точно кто будет делать, мы понимаем что уже делали эти задачи, и сколько времени это заняло. Так что это просто эксель с множеством пунктов, с примерными оценками в часах. И конечно так мы получаем предварительную оценку, которую потом можем экспертно корректировать. Как в сторону "что-то много получилось, клиент то небольшой", так и в сторону "да ну, явно не учли сложность, на одно общение с руководством половина времени уйдет". То есть от человеческого фактора в оценке мы не избавились конечно.
3. до 5% максимум, в среднем до 3% уходит на пресейл
4. К сожалению, проектов масштаба "почта России" или РЖД (так чтобы прямо знаковые) нет. Мы одни из немногих, кто внедряет БиТ.Финанс (кроме 1бит), и делает это успешно. Предпочитаем делать проекты с большим бизнес-обследованием (улучшениями, управлением изменениями, и т.д.). Кейсы тут есть corada.ru/nash-opyt/
5. я - гендир ) Но считаю что важно быть погруженным, так что далеко от проектного офиса и от наших клиентов не отхожу.