|
05.06.2017, 13:26 | #1 |
Модератор
|
Скорее, на начало. Т.е. 1С вышла на крупных заказчиков и сложные комплексные проекты, и столкнулась с тем, что мы проходили лет 15 назад. И это здорово: если кто-то уже проходил подобное, то накоплен опыт, сын ошибок трудных, и на него можно ориентироваться.
Кратко суммирую что писал на синьюсе: Это старая и известная проблема. Обсуждалась более 10 лет назад теми, кто внедрял ERP системы - Axapta / Sap / Scala / Infor и т.д. Тогда 1С была известная в основном только своей бухгалтерией. Хотя уже тогда была куча конфигураций, но внедрение состояло в настройке, а сопровождение - в наличие своего программиста (он же админ, он же обучение и поддержка), а франчи - просто привозили свежий диск ИТС. Теперь 1С полноценно играет на рынке ERP, вытесняя прочих игроков, и сталкивается с тем, что многие прошли десятилетие назад - управление партнерской сетью, контроль за качеством внедрений, разделение на тех, кто просто поставляет лицензии / итс и теми, кто действительно может сделать проект, со специализациями, сертификацией и т.д. Проблема, которую обозначил автор - глобальна, и касается не только ERP. Дело в том, что заказчик на уровне подбора команды не может сформировать требования к качеству проекта. Следовательно, кто-то всегда будет дешевле, правда, за счет качества. И выяснится это уже в ходе проекта, когда команда уже выбрана. Ведь внедрение ERP - это не настройка 4-6-10 конфигураций, склеенных кое-как. Это единая система со сквозными бизнес-процессами. И внедрять ее ой как непросто. И мало кто умеет это делать, особенно клиенты. Откуда они знают "требования к качеству"? Кто им расскажет, "как правильно"??. Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них. А тут приходи компания и говорит "а, зачем все это? сейчас adjle в моде, короче, готовьте 5 млн рублей и мы все сделаем". А потом оказывается, что на эти 5 млн рублей и ТЗ толком не напишешь, какое тут качество? Поэтому ВЕНДОРУ приходится учить заказчиков (и партнеров, или заказчиков через партнеров) как выбирать и внедрять систему, и наводить порядок в канале. Если вендор будет честно рассказывать про проектные риски, как правильно оценить проект и внедрить ERP-систему, и почему проект должен стоить не шапку сухарей, а вполне себе немаленькие деньги и, главное, почему это вложение разумное (как можно окупить вложения, или почему их вообще стоит делать) - это сильно поможет рынку. Этого никто не делал, так как боялся проиграть другому вендору (или партнеру). Но, в итоге, на большинстве ERP-проектов стреляли проектные риски, что приводило в сдвигам сроков проекта, запуску только части обозначенной функциональности, проект выходил за рамки бюджета и т.д. Что, в свою очередь дико раздражало заказчиков, и сформировало негативный фон к ERP в целом. С Уважением, Георгий |
|
05.06.2017, 16:01 | #2 |
Banned
|
Цитата:
Цитата:
Сообщение от George Nordic
Дело в том, что заказчик на уровне подбора команды не может сформировать требования к качеству проекта.
... Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них. Что делать? Убирать Вендора как слабое звено |
|
05.06.2017, 16:50 | #3 |
Модератор
|
Цитата:
Вот это свежая идея. "Взять все и поделить!" С Уважением, Георгий |
|
05.06.2017, 17:11 | #4 |
Administrator
|
Цитата:
Сообщение от George Nordic
Как делать предпроектное обследование, описывать функциональные и организационные требования к проекту, gap/fit анализ к выбираемой системе, правильно составлять план внедрения, ТЗ и требования к результату? Это сплошной матан для них. А тут приходи компания и говорит "а, зачем все это? сейчас adjle в моде, короче, готовьте 5 млн рублей и мы все сделаем". А потом оказывается, что на эти 5 млн рублей и ТЗ толком не напишешь, какое тут качество?
в бытность работы рафинированным бизнес аналитиком приходилось писать функциональные требования и ТЗ. напишешь на трех страничках - косо посмотрят, так "каждый дурак" может. допустим, описание функций отдела или процесса закупки получается на 80 - 140 страничек. и требует 10-ти виз на листочке согласований. и все знают, что если поставят свою визу, то потом их могут нагнуть. следовательно, читают долго. + просят внести изменения, после которых запускаем новый виток согласований. в итоге через полгодика топики процесс согласовали... а бизнес УЖЕ УШЕЛ!!! а разработка еще не начиналась! уже новые финансовые схемы, уже прошла маленькая реорганизация и из отдела закупок теперь появилось 3 отдела. и можно аккуратно порвать 140 страничек и сесть писать заново. приходила в голову мысль сразу под принтер шредер ставить... хотя бы время топиков сэкономить. так вот ТУТ я никакого КАЧЕСТВА не вижу. и таки да, я за Agile, при котором всегда не поздно свернуть. а в примере за это время были бы потрачены 5 лямов и была бы РАБОТОСПОСОБНАЯ и ОТТЕСТИРОВАННАЯ часть системы, пусть 20 или 80 процентов |
|
|
За это сообщение автора поблагодарили: macklakov (5). |
|
|