Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
>>А ИТшники товарищи заинтересованные. Либо в откате, либо в том, чтобы ничего не менялось.
Либо готовы работать с интегратором, поднять свой скилл, повысить свою цену на рынке.
п.с. Я понял, что это из вредных советов, если что))
нет никаких рекомендаций, просто перечень рисков, а как их получить или избежать - информации 0.
Гарантировано их избежать не получится, все равно многое остается на доверии конкретных людей. И от компетентности конкретной команды.
Я попробую варианты действий накидать.
"Магия низкого КП". Не контрится. Интеграторы будут минимизировать издержки через ограничение объемов, чтобы иметь шанс зайти в проект. Если он не сделает этого - шанса у него не будет. Но! Кто сказал, что минимальный функционал - это плохо? Слоника (особенно класса ЕРП) надо есть по частям. Сформулируйте минимальный набор требований, но так, чтобы на нем ваше предприятие смогло работать. Формулируйте их четко и конкретно, с возможностью проверки по объективным критериям - любой интегратор за такое спасибо скажет. Нам тоже туманные требования как кость в горле - обычно это означает, что заказчик сам не понимает, чего хочет, а это гарантированная нервотрепка при сдаче работ. Внезапно, мы тоже хотим честно и спокойно сделать полезную вам работу и получить за нее деньги, а не судиться за них годами.
Налог на имя. Все верно написано - известное имя не гарантирует эффективную команду. Оно лишь гарантирует ВОЗМОЖНОСТЬ интегратора содержать эффективную команду, в том числе между проектами. А отсутствие имени и истории - это 100%, что команда будет собираться с рынка, тк для нонейма содержать в штате даже 2-3 архитекторов за 400к + налоги в месяц невыносимо дорого. В лучшем случае там будет "звездочка" для пресейлов и тушения пожаров. Компенсация - см.п.4. Еще можно попросить РП и ФА рассказать, как они управляют проектной документацией, требованиями, техническими заданиями и тд. Если начинают лить воду - бегите. Случайные люди редко умеют в документацию, а без нее из-за постоянной ротации команды вы получите поделие, в котором никто не знает, что как работает и почему.
Игнорирование отраслевой специфики. Почти всегда - неизбежно. Исключения - если вы в узкой отрасли и нашли компанию, которая специализируется только на вашей отрасли, внедряя тиражное отраслевое решение. Но даже в таком случае готовьтесь ходить строем и ровно по тем линиям, что вам нарисует внедренец, ни о каких своих уникальных процессах можете не рассказывать. Хотели знатоков специфики - слушайте их, они знают как вам надо вести ваш бизнес лучше вас, они уже не один десяток таких контор автоматизировали. Если вы уникальны и не такой как вче - внедренцы будут учиться за ваш счет особенностям и вашей отрасли, и вашего предприятия. Но, в отличие от вас, они умеют учиться, потому что делают это постоянно. Поверьте человеку с опытом с обеих сторон, интенсивность потока информации у сотрудников внедренцев на порядки выше, чем у большинства заказчиков. Ну и перекрестное опыление идеями из разных отраслей и между разными предприятиями - это, в целом, тоже неплохо.
Покупка «презентации», а не команды. Компенсация: знакомиться с командой на этапе пресейла. Не обязательно всей, достаточно узнать руководителя проекта и функционального архитектора(ров), которые будут делать вам проект. Это ваши злейшие друзья на ближайшие год-два. Либо вы им верите - либо ищете других внедренцев.
С тобой соглашаются всегда. 100% признак разговора с продажниками, а не внедренцами. Хорошие РП и ФА будут уточнять, ограничивать, предлагать альтернативы в случае неадекватных требований. Не бейте их за это, они хотят как лучше - и вам, и себе. Себе - потому что именно им с вами акты подписывать, а не продажникам.
Отсутствие протокола Baseline/Scope/UAT/ФТ. 100% верно. Границы проекта - что делаем и чего не делаем - нужны, чтобы стороны понимали, что они продают/покупают, и по какой цене.
Я бы проще сформулировал. Нет процессов? Нет проекта по ЕРП. С функциональным подходом (требование заказчика - ЧТЗ на доработку) можно внедрить что-то небольшое и очевидное, но не ЕРП.
Выбор подрядчика силами закупщиков или ИТ-отдела. Проблема тут не в откатах, а в отсутствии у инициатора возможностей принимать решения, обязательные для других служб. Внедрение ЕРП затрагивает всех - и без поддержки и участия высшего руководства шансы на успех близки к нулю
Договоренности с интегратором на специализированных мероприятиях. Всему свое время. На мероприятии - первичное знакомство, там договоры не подписывают. Дальше - предварительные ласки и знакомство с командой, выводимой на проект.
Главное — это архитектурное виденье и умная концепция, а ручками поработать может кто угодно. Слышишь это, отключайся. Мы ищем проектную команду. Они сработаны, они притерлись друг к другу. Главный их минус - они не существуют. Даже в хорошей компании и хорошей сработанной команде есть текучка, особенно на горизонте нескольких лет. На разных проектах нужны разные компетенции, потому команды по итогам проектов вынуждено перетасовываются. Так что первое утверждение верно - важна архитектура и ее носители. Они определяют и обеспечивают в том числе и качество линейных сотрудников (учат или меняют), а также преемственность информации через документацию при замене линейного специалиста (аналитика или разработчика). Критичным удержание линейных спецов становится только там, где нет документирования, где управление и постановка задач делают в устном виде, называя свою некомпетентность "отсуствием бюрократии".
Все так, только бизнесу нужен результат сейчас а не завтра, и он не готов и не хочет ни во что вникать, а еще больше он не хочет ни за что платить. Бизнесу нужна волшебная желательно большая зеленая кнопка сделать все хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как гарантировано провалить проект 1С: 10 ошибок при выборе интегратора