Всем привет.
По моим ощущениям, на многих проектах этап согласования концептуального проекта затягивается на долгие месяцы. Ну а потом начинают "гнать коней" на стадии реализации. Нормально ли это и какие можно порекомендовать способы ускорения этапа согласования концепта?
Для затравки:
1. Прописать в уставе поекта:
- сотрудников клиента, отвественных за согласование
- максимальный срок, в течение которого эти сотрудники должны предоставить замечания или концепт считатется автоматически согласованным.
2. К каждому процессу рисовать поток документов. Не навороченный, как в арисе, а элементаный из нескольких квадратиков - типа заказ, поставка, фактура.

Еще один смежный вопрос - насколько часто на практике встречается подготовка прототипа? То есть при согласовании концепта уже показываются настроенные в САП на скорую руку кусочки процессов? Уменьшает такой подход общие сроки проекта или увеличивает?

По первому "затравочному" пункту:
- прописывание конкретных фамилий и должностей в Устав проекта может нетолько не помочь, но и сыграть злую шутку, если у заказчика высокая текучесть кадров (или процесс реинжиниринга или реформирования бизнеса). Потом еще труднее будет переподписать сам Устав. Хотя, по-хорошему, нужно переподписывать...
- на автосогласование заказчик вряд ли согласится, этим Вы у него рычаг воздействия отнимаете.

По второму: конечно рисовать, а еще лучше жирненько так выделять места, где будет разница между as-is и to-be, чтобы заказчик видел Вашу работу и понимал ее необходимость. ARIS он может и не поймет, а уж схемки из Визио ему понравятся (хотя все зависит непосредственно ситуации и лиц, в ней участвующих).
И вообще хорошо, привести ему вместе со схемками, проведенный анализ экономической эффективности от автоматизации конкретных процессов.

Ну это, как мне кажется, больше относится к этапу продажи САПа перед заключением контракта. Конкретного ключевого пользователя (начальника какого-нибудь отдела) не очень интересует экономическая эффективность для фирмы. Вот больше ему будет работы после внедрения или меньше - это интересует в первую очередь.

Ну, в идеале фамилии прописыватся в приложении к уставу, а в уставе прописывется возможность изменения этого приложения без переподписывания всего устава.

Без него вообще тяжко, иначе приходится долго размахивать руками и т.п.


Имхо, в концепте имеет смысл включать интеграционные аспекты, функциональные направлени и сквозные БП (т.е. межмодульные).
Т.о. есть шанс сократить концепт (и не превратить его в протокол настроек, в идеале - вообще не прописывать настроек). Касательно же детальных вещей - то неплохо получается действовать через проектные решения, в которых уже прописываем всё детально. Пишем ПР, отправляем на утверждение, сразу пишем второе, относительно слабосвязное, когда хоть что-то утверждается - можно делать настройки и показывать клиенту. Т.о. присутствует еще и обратная связь, т.к. клиент видит работу и ему уже можно показывать готовые куски.
+ получает экономия на протоколе настроек, когда проектные решения относительно малой кровью в него переходят.

По-моему, если Заказчик не знаком с SAP, показывать преднастроенные кусочки решений нужно обязательно. Настройка на одно проектное решение не занимает более дня, зато делает значительный прорыв в понимании Заказчиком того, как описанное в документе будет выглядеть наяву.
По-моему наиболее быстрое подписание получается при следующем алгоритме:
1. Заказчику передается проектное решение на предварительное ознакомление. В это время, пока Заказчик пытается вникнуть в то, что Вы ему написали, происходит преднастройка решения. Не нужно настраивать все "от сих до сих". Если это банковская выписка - показать регистрацию одной небольшой выписки в системе. Если это планирование закупок - показать создание заявки в системе, дать краткое описание ППМ.
2. Назначается встреча с ключевыми лицами Заказчика по данному ПР с целью обсуждения возникших вопросов и проведения небольшой демонстрации в системе.
3. После этого Заказчик возвращается под впечатлением от увиденного, с ответами на свои вопросы и переполненный доверием к консультанту И подписывает решение.

Если без демонстрации, обычно происходит так: проектное решение лежит на столе у ключевого пользователя. Он далеко не все в нем понимает и вообще может представить. Не всегда он готов признаться, что мало что понимает в том решении, которое должен подписывать. А подписывать не понимая, и брать на себя такую ответственность тоже не хочет. В итоге ПР лежит и лежит, покрываясь стопкой других бумаг...

Да, согласен, что на автосогласование вряд ли какой Заказчик пойдет. Зато в уставе нужно обязательно прописать кол-во дней, которой выделяется на согласование одного документа. А также, как мне кажется, было бы полезным завести в сети общедоступный ексель-файл, отслеживающий движение по согласованию ПР: консультант отправил ПР на согласование: указал в файле дату отправки и фамилию адресата. Адресат согласовал/написал свои замечания и вернул решение - сделал пометку в этом файле. Так сразу всем наглядно видно, по чьей вине идет задержка.

Ну и конечно много зависит от конкретного человека Заказчика. Кто-то визуал - ему надо все посмотреть. Кто-то, наоборот, не любит все эти встречи, а любит посидеть в одиночестве и внимательно и вдумчиво почитать документ.

Я делал так. Рассылал концепт ключевым сотрудникам заказчика, ответственным за согласование.
Через неделю приходил лично и обсуждал концепт, привлекая при необходимости необходимых специалистов.
Итого - полдня на одного специалиста, в течение недели мне удавалось согласовывать. Причем, с людьми, не знающими систему и без показов.

Это хорошо, если клиент в Москве, а если в какой-нибудь удалённой точке нашей родины, то это вряд ли сработает...

Может, лучше потратить неделю и съездить в эту удаленную точку, нежели несколько месяцев сидеть в теплой Москве, ожидая, когда же наконец заказчик соизволит прочитать и согласовать концепт.

Причина того, что так не сделано, вовсе не в том, что консультанты разленились и не хотят из теплой Москвы к заказчику ехать, а в том, что командировки заказчик оплачивает сверх суммы, указанной в контракте... вот они и "экономят"...

На мой взгляд самый эффективный ускоритель, это когда согласованием занимаются сотрудники самого заказчика включенные в проект.
Но они в этом случае должны, естесвенно чуствовать своё "авторство" в данном документе.

Прототип тоже очень помогает.

В принципе можно вообще построить работу так, что консультанты делают прототип, а сотрудники заказчика его описывают и это описание и есть концепт (хотя реально это сложно, вам должно сильно "повезти" с сотрудниками заказчика).
Согласование потом пойдет гораздо проще и быстрее.

Согласование по ПР вместо общего документа, на мой взгляд, процесс скорее затягивает чем ускоряет, кроме того снижает управляемость.

По моему мнению, показывать стандарт SAP ключевым пользователям на этапе КБП - это штука обоюдоострая. Если не понравится - не подпишут вообще, пока нормальный прототип не настроишь. Так можно себя загнать в ситуацию, что придется одновременно КБП писать-переписывать и прототип настраивать-перенастраивать. Такому ПМ консультанты быстро темную устроят.

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

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