Коллеги, спасибо за статью!
Применяем этот подход на практике и убеждаемся, что лед действительно тронулся: перемены и в умах Заказчиков, и в собственных позитивных результатах (в частности, скорости сдачи проектов).
Успехов!
Yakimchuk, «нет ответственного» стоит понимать как «отсутствие назначенного сотрудника (группы сотрудников)… ». Заказчик может быть представлен как в едином лице (глава канцелярии, СМК или департамента развития, а в небольших компаниях — это руководитель предприятия, ДИТ в связке с директором), так и может быть представлен группой ответственных, имеющих четкие границы разделения полномочий по процессам. В случае «составного» Заказчика необходим такой орган управления проектом со стороны клиента как Управляющий комитет, привлекаемый для принятия стратегических решений по проекту, а также в случаях принятия решений об изменении бюджета/функциональных или календарных границ.
Отсутствие Заказчика может привести гарантированно к задержке сроков согласования и утверждения результата проекта, не возможности принятия решений в ходе спорных ситуаций внутри рабочей группы, а, самое главное, отсутствие примера и авторитета в ходе внедрения. А это значит, неуспешность проекта почти гарантированна. Предупредить об этом клиента, на мой взгляд, профессионально важно и этично.
Yurich, в Вашем случае «ножного» согласования одно спасение — приделать документам «быстрые ноги», что означает заиметь замотивированного Заказчика. Вот пример из практики: крупное промышленное предприятие со штатом пользователей на 1-ю очередь внедрения 200 пользователей, выбрали систему, согласовали внедрение, посетили 2 региональных референс-клиента, включая переговоры с вендором — за 1,5 (!) месяца. Стоял жесткий срок, у процесса был влиятельный лидер, в компании НЕ БЫЛО СЭД до этого.
А компании, о которых Вы говорите, мы тоже встречаем ежедневно. И «реанимируем» проекты от подпорок в том числе. Как и писала в ответах всем активным и думающим читателям, каждой задаче — адекватный инструмент. Если в компании 15 чел, среди которых в согласованием документов занимается 3, а документов к согласованию, к пример, в год не больше 100, смысла ставить им СЭД — нет, согласуйте документы в том же Dropbox на здоровье и будьте счастливы)
northbear, да, как и Вы, не хотела бы встретиться с таким исполнителем!) Вы правы в том, что от Исполнителя тоже много зависит. а я бы расширила горизонт: процесс выбора и внедрения — вещь обоюдная, все как в семье, счастье зависит от вклада обеих сторон. Дай Бог всем добросовестных Исполнителей, которые «слабости» Заказчика превращаюст в ходе проекта «в силу», которые поддерживают и строят крепкие отношения! Обращайтесь, если что, мы разделяем эти ценности!))
staskin1, благодарю за интересный вопрос!
Отчасти, да — сбор требований, обследование и т.д. Но, задумайтесь, почему, вроде бы, все делают «по учебнику», но не каждый проект проходит гладко? Важно, КАК и КАКИЕ вопросы в этом обследовании задавать и КАКИЕ отношения уже выстроены с Заказчиком (доверительные, диалог профессионалов, на уровне «я-ок — ты-ок»). Успех в том, что вопросы надо задавать откровенные, где-то неудобные, да, Заказчику не всегда приятно говорить о тех областях, где неладно, где болит, где беспорядок. Но важно пройти с ним вместе этот этап. Иначе самая суть будет скрыта за пеленой «водных» целей вида «повысить эффективность», «снизить издержки». Все это не имеет смысла пока цели не прописаны до деталей. Например, достижение экономического эффекта от внедрения системы путем включения показателей исполнительской дисциплины в систему мотивацию каждого сотрудника. М, чувствуется разница? Вот из воды и надо выводить Заказчика на сушу. Методология вся хороша. Важно, как вы ее исполняете. Удачи!
Quiz, поддерживаю Вас на 200%! В этом и различие в «голодном» и «грамотном» подходе)) Кто-то из Исполнителей радуется, что Заказчик испытывает невероятный аппетит и хочет многого. При этом получает на выходе проект, сдать который невозможно даже теоритически, поскольку результат ни померить, ни ощутить. А кто-то пусть и фрустрирует Заказчика «противопоказаниями», но при этом получает благодарного ПАРТНЕРА, потому что сразу объяснил и отказался делать «все, везде и вчера». Поделился, что стоит наладить ДО внедрения, о чем подумать, где порядок навести. Ведь асфальт тоже почему-то не везде хорошо держится!)))) Спасибо за мнение! Успехов!
lair, спасибо за вопрос!
Поскольку внедрение СЭД стоит рассматривать как частный случай более глобального явления — «автоматизация бизнесс-процессов на уровне компании», то, думаю, и перечень «противопоказаний», специфичных для СЭД, скорее частный случай сводного списка, составленного из данных смежных внедрений. По своему опыту участия в проектах внедрения и ERP- и CRM-систем могу сказать, что все эти «частности» встречались и там. Плюс добавлялись «предметные слабости» + особенности и глубина интеграции, например.
Есть еще одна история, которая встречается, пожалуй, вне зависимости от типа внедрения и носит скорее характер, как я его называю, «менеджерского вируса» — впихнуть в границы автоматизации не только типовые задачи (в случае ЭД — управления контентом), но и «все и вся», (начиная от управления проектами до создания кабинета виртуального обучения). Смотреть на творческое бурление умов невероятно захватывающе, но, на мой взгляд, важно это корректно и вовремя остановить, обсудив «чуждые требования» и порекомендовав «пылесосить все-таки пылесосом». И тут уже то самое волшебное чувство доверия между сторонами, когда открыто и честно, без «ванильных» ожиданий можно все обсудить и договориться, помогает конструктивно договориться.
Применяем этот подход на практике и убеждаемся, что лед действительно тронулся: перемены и в умах Заказчиков, и в собственных позитивных результатах (в частности, скорости сдачи проектов).
Успехов!
Отсутствие Заказчика может привести гарантированно к задержке сроков согласования и утверждения результата проекта, не возможности принятия решений в ходе спорных ситуаций внутри рабочей группы, а, самое главное, отсутствие примера и авторитета в ходе внедрения. А это значит, неуспешность проекта почти гарантированна. Предупредить об этом клиента, на мой взгляд, профессионально важно и этично.
А компании, о которых Вы говорите, мы тоже встречаем ежедневно. И «реанимируем» проекты от подпорок в том числе. Как и писала в ответах всем активным и думающим читателям, каждой задаче — адекватный инструмент. Если в компании 15 чел, среди которых в согласованием документов занимается 3, а документов к согласованию, к пример, в год не больше 100, смысла ставить им СЭД — нет, согласуйте документы в том же Dropbox на здоровье и будьте счастливы)
Отчасти, да — сбор требований, обследование и т.д. Но, задумайтесь, почему, вроде бы, все делают «по учебнику», но не каждый проект проходит гладко? Важно, КАК и КАКИЕ вопросы в этом обследовании задавать и КАКИЕ отношения уже выстроены с Заказчиком (доверительные, диалог профессионалов, на уровне «я-ок — ты-ок»). Успех в том, что вопросы надо задавать откровенные, где-то неудобные, да, Заказчику не всегда приятно говорить о тех областях, где неладно, где болит, где беспорядок. Но важно пройти с ним вместе этот этап. Иначе самая суть будет скрыта за пеленой «водных» целей вида «повысить эффективность», «снизить издержки». Все это не имеет смысла пока цели не прописаны до деталей. Например, достижение экономического эффекта от внедрения системы путем включения показателей исполнительской дисциплины в систему мотивацию каждого сотрудника. М, чувствуется разница? Вот из воды и надо выводить Заказчика на сушу. Методология вся хороша. Важно, как вы ее исполняете. Удачи!
Поскольку внедрение СЭД стоит рассматривать как частный случай более глобального явления — «автоматизация бизнесс-процессов на уровне компании», то, думаю, и перечень «противопоказаний», специфичных для СЭД, скорее частный случай сводного списка, составленного из данных смежных внедрений. По своему опыту участия в проектах внедрения и ERP- и CRM-систем могу сказать, что все эти «частности» встречались и там. Плюс добавлялись «предметные слабости» + особенности и глубина интеграции, например.
Есть еще одна история, которая встречается, пожалуй, вне зависимости от типа внедрения и носит скорее характер, как я его называю, «менеджерского вируса» — впихнуть в границы автоматизации не только типовые задачи (в случае ЭД — управления контентом), но и «все и вся», (начиная от управления проектами до создания кабинета виртуального обучения). Смотреть на творческое бурление умов невероятно захватывающе, но, на мой взгляд, важно это корректно и вовремя остановить, обсудив «чуждые требования» и порекомендовав «пылесосить все-таки пылесосом». И тут уже то самое волшебное чувство доверия между сторонами, когда открыто и честно, без «ванильных» ожиданий можно все обсудить и договориться, помогает конструктивно договориться.