05.01.2010, 21:00 | #1 |
Участник
|
Программировать самим или внешняя компания
Добрый день,
ведем дискуссию у себя в компании по поводу дальнейшей стратегии развития системы Ах. У нас много компаний в Ах, интенсивно развивается деятельность, делается не мало изменений. Работая с компанией вндернецов иногда элементарные вещи делаются очень долго и к сожалению дорого, плюс не развиваются компетенции внутри компании. Могли бы поделиться опытом или посоветовать какой путь выбрать свой программист и разработка своими силами или внедренчиская компания? Какие плюсы и минусы? Спасибо! |
|
05.01.2010, 21:46 | #2 |
Участник
|
Цитата:
В двух словах (мое личное мнение): 1. Консалтеры - это как форсаж. Плюс: Позволяют определить направление, преодолеть инерцию покоя и внутрикорпоративные разногласия. Консалтеры позволяют добиться быстрого разгона и быстро достичь взлетной скорости. Минусы: Затратно. Как орбит-форсаж. И если они дадут неверное направление, то изменить направление или спастись очень трудно. Как при форсаже. 2. В какой-то момент нужно отказываться от консультантов (как от форсажа) и переходить на нормальную тягу силами своих специалистов. см. например, работа в консалтинге vs. на клиенте Бизнес-аналитик VS Консультант Когда нужен системный аналитик на проекте? а также Cтоит ли программистов огораживать консультантами от пользователей? Про консультантский подход |
|
|
За это сообщение автора поблагодарили: EVGL (2), kaw (1), konopello (3). |
06.01.2010, 12:24 | #3 |
Аманд
|
Можете ещё здесь почитать:
Amand: Внедрение ERP: Найти взаимопонимание Клиент-Эксперт-Внедренец. Здесь моё мнение о подходах к развитию системы: http://www.amand.ru/modules/wordpress/archives/67 Цитата:
В какой-то момент нужно отказываться от консультантов (как от форсажа) и переходить на нормальную тягу силами своих специалистов.
Цитата:
Могли бы поделиться опытом или посоветовать какой путь выбрать свой программист и разработка своими силами или внедренческая компания? Какие плюсы и минусы?
Проще говоря, каждый будет заниматься своим делом: определённые задачи может решать внутренняя команда, определённые внешняя, концептуальные задачи рабочая группа и т.д. Ключевое слово - определённые задачи. То есть - нужно чётко определить, какие задачи - кем решаются. И здесь необходимо использовать как формальные факторы: время реакции, стоимость и т.д., так и неформальные, о которых я писал в блоге. Неформальные факторы сложнее всего определить, так как они, чаще всего скрыты от внутренней команды и незаметны внешней. |
|
06.01.2010, 21:30 | #4 |
Гость
|
Судя по вопросу, Вы ужe почти опрeдeлились. Добaвлю, что прeдстaвитeли консaлтинговых компaний выскaзaлись в этой вeткe. Если Вaс устрaивaeт стиль их отвeтов с вeрeницeй ссылок, 'форсaжeй' и 'вeкторов', то Вaм, скорee всeго, будeт интeрeсeн будeт опыт взaимодeйствия с ними. Примeрно тaк жe будeт строиться диaлог кaк с ужe отмeтившимися прeдстaвитeлями, тaк и с любыми другими из этой диaспоры. Лично я нe вижу смыслa пeрeплaчивaть зa подобного родa информaцию, учитывaя, что от сотрудникa в штaтe eё можно получить дeшeвлe, быстрee и, зaчaстую, с бОльшим коэффициeнтом 'попaдaния' и прeбывaния 'в тeмe'.
|
|
07.01.2010, 01:32 | #5 |
Member
|
Свой разработчик как правило существенно дешевле. Более контролируем (управляем) компанией. Чаще лучше знает бизнес-процессы компании (в длительной перспективе). Мотивирован на интересы компании (консультант или программист консалтинговой компании мотивирован на актирование работ). Не перебрасывается на другие проекты, даже если они более прибыльны.
Свой разработчик может уйти, унеся знания. Впрочем, с консалтингом такое тоже вполне возможно (общий риск). Но со своим разработчиком обычно больнее получается. Свой разработчик может не обладать квалификацией в специфических областях. Свой разработчик может иметь не настолько обширный опыт как разработчик консалтинговой компании (что может сказаться на качестве некоторых решений). У своего разработчика может быть ниже качество кода. Свой разработчик может меньше пользоваться знаниями консультантов, возмещая это способностью программировать. IMHO, в долгосрочной перспективе эффективные внедрения как правило бывают только тогда, когда заказчик полностью контролирует процесс внедрения на уровне архитектуры решения, приоритетов задач, сроков и качества исполнения. Для этого важно иметь контакт с пользователями (не только и даже не столько операторами, вводящими данные, но и аналитиками, топменеджерами). А вот кто будет непосредственно выполнять работы в таком случае — технически без разницы. Весьма эффективны бывают такие решения. 1. Заказчик и разработчик от конечного пользователя, консультант периодически привлекается для разработки дизайна. 2. Текущая поддержка пользователя и несложная текущая разработка на штатном разработчике, консалтинг и разработка для разовых крупных задач на консалтинговой компании. 3. Все делается силами штатных специалистов, но часть разработки сдается на аутсорс. Если вы спросите про консалтинг, то там целесообразность привлечения внешних специалистов существенно более насущная. Особенно на старте внедрения. Особенно если штатная команда не очень сильная, опытная, и не совершенно знает функционал системы. Но. Если сильно обобщить... Образно я бы сказал так. Чем лучше штатная команда сама контролирует процесс, тем больше эффекта (= польза / потраченные деньги) вы получите как и от привлеченного консультанта, так и от привлеченного программиста. Косвенно о том, насколько хорошо вы контролируете процесс, будет говорить то, насколько локальные задачи вы ставите, и насколько тщательно контролируете результат их исполнения.
__________________
С уважением, glibs® |
|
|
За это сообщение автора поблагодарили: BOAL (1). |
07.01.2010, 14:45 | #6 |
Участник
|
Цитата:
Если один или оба программиста сильны настолько, что могут адекватно общаться с пользователями и, грубо говоря, сами себе делать постановку задачи, либо есть сильно продвинутые пользователи, способные грамотно ставить задачи напрямую программистам, то можно обойтись и одним консультантом-аналитиком. Повторюсь: в расчете на 50 активных пользователей. Активных считать как максимальное число юзеров, работающих одновременно в системе. Например, может быть так: в Аксапте зарегистрировано и в течение месяца периодически работают 200 человек, но при этом в течение дня входят 100 человек, и при этом максимально в течение дня одновременно работают 50 человек - то вот эти 50 и считать. Аутсорс считаю наихудшим вариантом, в особенности если это единственный применяемый на предприятии способ подержки и развития системы. |
|