Организация эффективного процесса внедрения на проектах промышленного масштаба
Мы хотели бы поделиться опытом: того, с чем мы сталкиваемся, и того, что мы кровью и потом наработали с нашими заказчиками – у нас достаточно крупные и проблематичные заказчики – типа ГазпромНефти и Почты России.
То, о чем я буду рассказывать, по большей части актуально для крупных структур, когда у вас есть головная компания и филиалы, ДЗО, которые обладают различной степенью самостоятельности и различным видением одних и тех же процессов, чем сильно усложняют процесс внедрения.
Статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.
То, о чем я буду рассказывать, по большей части актуально для крупных структур, когда у вас есть головная компания и филиалы, ДЗО, которые обладают различной степенью самостоятельности и различным видением одних и тех же процессов, чем сильно усложняют процесс внедрения.
Статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Говорил уже и повторю ещё: все эти красивости совершенно не имеют значения. Ни квалификация внедренцев, ни качество продукта, ни проработка бизнес-процессов не имеют значения. Важно только одно - наличие административного ресурса. Если он будет, то и самую кривую конфу будут юзать "на ура", а несогласных просто нагнут приказным порядком; а если явление "кулаком по столу" отсутствует, то и трижды крутая разработка с отличным теоретическим обоснованием и опытом внедрения тихо отправляется на помойку, а люди копошатся в привычных экселях.
(0) по Тест-центр, овчинка выделки не стоит. Никаких метрик не собирается, ни по железу, ни по 1с. Вроде тест есть, а понять в относительных величинах "при увеличении пользователей на 20% насколько у нас будет простаивать железо или увеличится среднее ожидание на транзакции" ответа получить не возможно, или например "сейчас в день 1000 документов, при увеличении до 2000 на что необходимо обратить внимание на железо и конфгурацию?" и т.д. Конечно, может у меня были большие ожидания от тест-центра, но вот анализ и сравнение показателей я там не увидел, поиск корреляций, даже простейшие метрики "средняя длина транзакции", количество ошибок, количество отмененных транзакций и т.д. я не увидел.
Административный ресурс должен быть обязательно, без него внедрения не будет. Но вот если административный ресурс адекватный, то Вы Yashazz со своим подходом вылетите с проекта очень быстро. Это я как руководитель проекта со стороны заказчика Вам говорю.
(5) bondar_vy@mail.ru, вы, вероятно, не поняли. Я не призываю к внедрению кривого-ушатанного продукта, я указываю на вероятность успеха и основные факторы. Адекватный адм.ресурс - это сферический конь в вакууме. Как максимум можно рассчитывать на дядю, который поинтересуется финальным "работает-не работает", или случайно оказавшегося "во власти" собрата-айтишника. Далее адекватность кончается. Можно сделать супер-продукт и убиться об стену, пытаясь сделать так, чтобы он использовался, даже при адекватном начальстве; это я вам как руководитель множества проектов говорю. Есть итальянская забастовка и прочие способы тихого саботажа, потому что " ну мне так привычнее" и "я этой вашей 1С не доверяю, я лучше параллельно в эксельчике буду всё вести". И повторяю, это никак не связано с качеством "вашей 1С".
Вылетают с проектов обычно те, кто больше "высовывается", машет руками и вообще возмущает спокойствие, потому что, чем больше и, значит, бюрократизированней организация, тем меньше руководство интересует реальная эффективность и "конечный выход". Интересует стабильность и соблюдение формальностей, да иногда пилёжка доступных средств без помех. Однажды вы это поймёте)
Ковбойская пословица: "и один человек может привести лошадь на водопой, но даже десятеро не заставят её пить".
Вылетают с проектов обычно те, кто больше "высовывается", машет руками и вообще возмущает спокойствие, потому что, чем больше и, значит, бюрократизированней организация, тем меньше руководство интересует реальная эффективность и "конечный выход". Интересует стабильность и соблюдение формальностей, да иногда пилёжка доступных средств без помех. Однажды вы это поймёте)
Ковбойская пословица: "и один человек может привести лошадь на водопой, но даже десятеро не заставят её пить".
Автор, отличный материал! А можно выложить схему управления инцидентами в лучшем качестве? Или статейку, по личному опыту на эту тему, а то эти все itil и pmbook вяло в практику серых будней вливаются, особенно на малых проектах. Интересует не описание хелпдеска, а скорее принципы, фундамент, на котором он строится.
Спасибо.
Спасибо.
(0) Со многими пунктами согласен, но есть вопросы.
Государственные предприятия, особенно крупные, работают через механизм открытых тендеров. Для этого им нужно ТЗ на все работы от начала до конца. И договор на основании ТЗ на полную стоимость проекта. Как от водопадной модели безболезненно перейти к итеративно-цилической? Или все равно мухи отдельно, а котлеты отдельно? Гибкие технологии гораздо имеют массу плюсов, но и б'ольшие расходы для достижения того же результата. В водопадной модели мы как-никак идем прямо к результату, а в гибкой на каждой итерации стараемся направиться более точно к видимой цели. При отказе от следования ТЗ нет страховки, что заказчик на n-ом шаге не поймет, что ошибался в начальных требованиях, и не попросит вернуться к первому шагу. Как юридически строить отношения с крупными государственными заказчиками в случае гибкой разработки?
Все знают, что в свежих релизах платформы огромное количество багов. Есть ли опыт реальной разработки конфигураций с использованием БСП, как много ошибок встречается там? Вы правили их сами или через разработчиков из 1С?
Государственные предприятия, особенно крупные, работают через механизм открытых тендеров. Для этого им нужно ТЗ на все работы от начала до конца. И договор на основании ТЗ на полную стоимость проекта. Как от водопадной модели безболезненно перейти к итеративно-цилической? Или все равно мухи отдельно, а котлеты отдельно? Гибкие технологии гораздо имеют массу плюсов, но и б'ольшие расходы для достижения того же результата. В водопадной модели мы как-никак идем прямо к результату, а в гибкой на каждой итерации стараемся направиться более точно к видимой цели. При отказе от следования ТЗ нет страховки, что заказчик на n-ом шаге не поймет, что ошибался в начальных требованиях, и не попросит вернуться к первому шагу. Как юридически строить отношения с крупными государственными заказчиками в случае гибкой разработки?
Все знают, что в свежих релизах платформы огромное количество багов. Есть ли опыт реальной разработки конфигураций с использованием БСП, как много ошибок встречается там? Вы правили их сами или через разработчиков из 1С?
Ничего не понятно в статье. Как-то сумбурно. Одно вот заинтересовало. Пишите
у нас достаточно крупные и проблематичные заказчики – типа ГазпромНефти и Почты России.
С вторым, да, согласен. Особенно когда работать в штате с целью наработки опыта внедрения. А вот с первым удивлен. Там же денег куры не клюют?
Очень интересен чисто денежный аспект. Как правило, заказчик хочет оценку бюджета и затем оценивать его исполнимость (освоенность).
Как вы решали эту проблему ?
Понятно что при многоитерационном подходе рождались десятки мини-ТЗ и мини-бюджетов. И неужели ни один из них не сказал: "Эй, ребята, а сколько еще надо чтобы это все закончилось ?" ?
Как вы решали эту проблему ?
Понятно что при многоитерационном подходе рождались десятки мини-ТЗ и мини-бюджетов. И неужели ни один из них не сказал: "Эй, ребята, а сколько еще надо чтобы это все закончилось ?" ?