![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
Блог НЕ рассматривает вопросы программирования. Если Вас интересуют вопросы разработки, рекомендую общеизвестный ресурс www.mmcrm.ru.
Если Вам понравились материалы, буду рад видеть Вас в друзьях. Также Вы можете задавать вопросы и я постараюсь на них ответить максимально развернуто.
Надеюсь информация будет полезна для Вас. Приятного просмотра.
С Уважением, Джафаров Дмитрий
- Вт, 12:08: Microsoft Dynamics CRM 2011 Импорт данных http://t.co/TwysOJt0
- Вт, 12:14: Microsoft Dynamica CRM 2011 Импорт данных http://t.co/g46hmQIK
Прошу прощение за обрезанное видео. Если кому то очень хочется узнать, а что же было сверху - я могу переснять, но в целом я уверен все понятно.
Как вы уже поняли видео ориентировано на новичков в CRM ну или тех, кто ни разу в жизни не трогал функциональность системы с точки зрения импорта информации.
Я хочу добавить несколько комментариев:
- В видео я показал загрузку через выгрузку шаблона. Т.е. вы сначала загружаете шаблон с CRM, а уже потом в нем производите редактирование. Это не единственная возможность. Вы также можете взять свой файл и загрузить его. При этом система попросит сопоставить поля. В целом ничего сложного нет и все интуитивно понятно, но для упрощения процедуры рекомендую пользоваться показанным способом.
- При сопоставлении полей очень часто возникает проблема с полями Имя, фамилия, отчество. Их по 2шт. Это результат не совсем корректного перевода названия полей ну русский язык. Для ФИО есть дублирующие поля, предназначенные для ввода иероглифов (Yomi). Я очень рекомендую на этапе настройки объектов изменить атрибуты названия на русском языке для этих полей (поменять в названии полей Имя, Фамилия, Отчество на Имя-yomi, Фамилия-yomi, отчество-yomi). Если вы последуете этой рекомендации у вас не будет проблем с идентификацией полей при сопоставлении.
- Пт, 09:13: Завершил создание прототипа для кредитного процесса в Банке. Получилось быстро по времени и очень хорошо по качеству. Клиент остался доволен
- Пт, 09:15: Паралельно работаем по редизайну своего сайта www.xrm2b.ru. Хочется создать очень информативный ресурс ориентированнй не только наклиентов.
- Вт, 15:56: 3 дня назад начал делать прототип для Банка (кредитный фронт). Сегодня с удовольствием констатировал завершение настройки объектов и форм.
- Вт, 15:58: @jeffmagness Nice to meet you;-)
- Сб, 07:33: 17 удивительных визиток, которые хочется сохранить : E-xecutive http://t.co/xWLskV3 с помощью @executive_ru
- Пт, 13:05: RT @CRM_ua: если Вы не можете решить аренда или внедрение СРМ, возможно, Вам поможет эта статья http://t.co/sSNClOU
- Пт, 13:06: Я ищу логический ответ на вопрос - почему в Micsrosoft Dynamics CRM нет связи 1:1 ? Помогите с ответом!
- Чт, 10:14: Создание информационной системы. Делать своими силами или привлечь внешнего исполнителя? http://j.mp/pUJhz5
SWOT (персонал свой)
Сильные стороны (Strengths)
- Собственная устойчивая команда с высоким уровнем доверия.
- Неограниченный бюджет (ниже в статье будет приведен анализ стоимости работы собственных специалистов.
- Слабые стороны (Weaknesses)
- Отсутствие разнообразия практик (новые практики приходится начинать путем проб и ошибок). У существующей команды нет экспертизы для новых направлений деятельности (универсальных специалистов нет, есть специалисты обладающие большой разнообразной экспертизой, готовые изучать новые направления).
- Высокая зависимость от собственного персонала (риск болезней, плановые отпуска). Также есть риск переход сотрудника к конкуренту, а в месте с этим, возможная потеря экспертизы, а возможно и коммерческой информации.
- Мотивация мало эффективна (плохому сотруднику не получится не заплатить зарплату, а уволить его тоже достаточно сложно).
- Высокий уровень затрат:
- Стоимость персонала очень высока (минимальная профессиональная команда из 3х человек стоит от 350 тыс. рублей в месяц – расходы на заработную плату плюс налоги).
- Аренда офиса, амортизация техники.
- Затраты устойчивые даже в случае простоя (персонал быстро не уволить, от аренды не отказаться).
Возможности (Opportunities)
- Эффективная реализация поставленных задач в установленные сроки (в рамках имеющегося экспертного опыта).
- Привлечение заказчика за счет демонстрации собственной экспертизы.
- Возможность иметь партнерский статус вендора (некоторые вендоры предъявляют требования к необходимости иметь набор собственных специалистов, обладающих определенной квалификацией).
Угрозы (Threats)
- Отказ бизнес заказчика от проекта по причине высокой себестоимости/стоимости.
- Риск потери контракта в следствии нехватки персонала.
- На рынке очень мало свободного профессионального персонала, готового перейти в Вашу компанию.
- Риск простоя в связи с отсутствием заказа, а как следствие не покрываемые доходом издержки.
SWOT (внешние Консультанты)
Сильные стороны (Strengths)
- Эффективная мотивация (оплата труда по договору за реально выполненные объемы работ т.е. не сделано – не заплачено).
- Эффективные затраты (работа закончилась затраты исчезли т.е. нет риска простоя). На этап привлекаются только те специалисты, которые нужны именно в данный момент.
- Нет юридической зависимости от внешнего исполнителя (имеется ввиду трудовое законодательство).
- В случае проблем с исполнителем его можно заменить.
- Внешний исполнитель не будет иметь доступ к Вашей коммерческой информации (или этот доступ можно ограничить до разумных рамок).
Слабые стороны (Weaknesses)
- Сложный менеджмент отношений с внешним исполнителем (более сложные коммуникации, контроль исполнения и т.д.).
- Стоимость работы внешнего исполнителя выше зарплаты аналогичных собственных специалистов.
Возможности (Opportunities)
- Выход на новые рынки. У внешних исполнителей зачастую очень разнообразная экспертиза.
- Эффективная реализация проекта (внешний исполнитель мотивирован контрактными условиями, также Вы можете менять исполнителя в процессе проекта).
- У Внешнего исполнителя зачастую есть хорошие рекомендации.
Угрозы (Threats)
- Невыполнение исполнителем работ. У внешнего исполнителя зачастую меньше ответственности перед Вами чем у Вас перед заказчиком.
- Интересующий внешний исполнитель может быть недоступен в интересующий Вас промежуток времени (необходимо заранее договариваться).
- Заказчик может негативно воспринять работу на проекте третьей стороны.
Изучив оба SWOT анализа каждый делает свой выбор в пользу работы с собственными специалистами или в пользу внешнего исполнителя. Рассмотрим основные факторы:
Анализ стоимости владения (TCO - Total cost of ownership)
С моей точки зрения ключевым фактором, определяющим правильность выбора является экономика. Если сделать расчет совокупной стоимости владения (TCO) даже по прямым затратам получится цифра в несколько раз превышающая стоимость работы внешнего исполнителя. Очень часто со мной не соглашаются, и я привожу пример:
Задача: автоматизация процесса оптовых продаж.
Кол-во трудочасов: 700 часов.
Длительность проекта 3 месяца.
Стоимость:
А) 1,5 тыс. рублей / час за внешнего специалиста.
Б) 80 000 р / месяц за одного специалиста.
Итак, стоимость разработки в нашем случае составит:
А) 1 050 000 рублей в случае привлечения внешнего специалиста.
Б) Зарплата: 2 специалиста в течение 3х месяцев получат ЗП в размере 480 000 рублей, дополнительные расходы в виде налогов составят приблизительно 250 000. Необходимо купить оборудование 80 000 рублей. Также заплатим за аренду (10 кв. м по 1000 рублей) 30 000 р. Итого, прямые затраты 840 000 рублей.
Вывод напрашивается сам собой – выгоднее брать своих специалистов, но мы забыли посчитать сколько будет стоить поддержка решения. В случае, если мы привлекаем внешних консультантов, год поддержки обойдется в 240 000 рублей, а свои специалисты обойдутся нам в 2 800 000 рублей (и это без налогов и сборов).
Вывод: Таким образом, привлечение внешних консультантов и год поддержки обойдется в 1 390 000 рублей, а свои специалисты обойдутся в 3 640 000 р, что почти в 3 раза дороже привлечения внешних специалистов.
HR
Привлечение своих специалистов накладывает обязательства в рамках трудового законодательства. Даже если специалист отработал плохо с вашей точки зрения, в большинстве случае Вы все равно будете вынуждены платить ему зарплату. В противном случае он имеет шанс создать для Вас, а как следствие для проекта, очень большие проблемы.
Также нельзя забывать, что свободных специалистов на рынке нет. Или почти нет. Привлекая внешних специалистов Вам не надо заботиться о многомесячном поиске персонала.
По завершению проекта зачастую возникают ситуации когда необходимо отказаться от ряда специалистов. Увольнять просто так нельзя. Это запрещено. Сокращение специалистов дорогое мероприятие. В случае выбора внешнего исполнителя оплата заканчивается тогда, когда завершается проект.
Проектное управление и работа на проекте
Часто возникают ситуации, когда свои специалисты в силу ряда причин могут не справляться с поставленными задачами в установленные сроки. Внешних исполнителей можно легко заменить.
Необходимо понимать, на проекте работают разные специалисты на разных этапах. Это значит что, допустим, разработчик не нужен на первом этапе анализа, а консультант не сильно загружен на этапе разработки. В случае если это свои специалисты, они будут получать зарплату, а Вы фиксировать накладные расходы. Внешний исполнитель привлекает тех специалистов в том объеме, которые нужны для решения задач этапа.
Работа с внешними исполнителями дает доступ к более широкой экспертизе т.к. возникает возможность выбора специалистов.
Трудный выбор
Анализ, представленный в данной статье не претендует на роль единственно верного. Не бывает ни одного абсолютно похожего проекта. Разные ситуации требуют разных подходов и разных решений. Тем не менее всегда необходимо широко взглянуть на проект и постараться найти все плюсы и минусы в решении которое вы выберете для себя. Лично с моей точки зрения решение иметь собственную команду должно быть очень серьезно оправдано.
Стоимость специалистов в настоящий момент в России составляет от 2500$/месяц (в руки и без налогов), фрилансеры стоят дороже, приблизительно 50$ за один час, также существуют консалтинговые компании,стоимость которых может составлять более 100$ час, но не забывайте, что они работают только в рамках реальных трудочасов.
Выбор за Вами. Я надеюсь, что представленная в статье информация поможет сделать более правильный выбор или пересмотреть существующую стратегию в сторону повышения эффективности.
Прошу Вас потратить несколько минут и написать свое мнение.
- Пт, 19:06: Update Rollup 3 for Microsoft Dynamics CRM 2011 http://j.mp/oXwDNV
- Пт, 20:03: Бизнес кейс 2 На этот раз я предлагаю Бизнес-кейс для обсуждения. Я буду рад за предложенные варианты решения. Входные … http://j.mp/pVeYVY
На этот раз я предлагаю Бизнес-кейс для обсуждения. Я буду рад за предложенные варианты решения.
Входные данные:
- Цель – кредитный фронт (оформление потребкредитов для физических лиц), интеграция со Scoring , БКИ, Share Point Server 2010.
- Платформа - Microsoft Dynamics CRM 2011.
- Заказчик – крупный банк.
- Начало работы по договору – 20 мая.
- Сроки - 15 июня надо продемонстрировать полноценный работающий прототип с интеграцией, 01 июля выход на промышленную эксплуатацию. Итого 29 рабочих дней.
- Интеграция с внешними системами – Scoring, БКИ.
- Бюджет – перезаложен.
- Проект очень политизирован. Заказчик не намерен изменять сроки.
- Потребительское кредитование – новый продукт для заказчика. Из описания есть только схема процесса.
- Ожидаемый срок подключения к кредитному бюро, разработка рабочей модели скоринга – первая декада июня.
- В процессе работы необходимо мигрировать существующее досье клиента, реализованное на WSS на Share Pont Server 2010 и обеспечить интеграцию SP 2010 с CRM .
- Реализовать заявленную функциональность в установленные сроки.
- Допускается к 15 июня не демонстрировать рабочее подключение к БКИ и рабочий скоринг.
Все мы периодически сталкиваемся с разнообразными ситуациями и проблемами, эффективное решение которых подчас неочевидно и сложно. Я постараюсь раскрыть некоторые из них в описании бизнес-кейсов, а Вы можете помочь своими вариантами решения кейса, комментариями и примерами.
Итак, Бизнес-кейс 1
Входные данные:
Заказчик – государственная компания.
Начало работы по договору – 1 августа.
Срок производства - до 31 декабря (т.е. 5 месяцев с момента подписания договора). При этом к 31 декабря надо закрыть договор актом, а реальный срок до августа следующего года.
Бюджет – 2 раза перезаложен от нормы.
Цель – система управления отношениями (CRM) в государственном учреждении (функциональные требования понятны).
Особенности проекта:
На 1 августа нет функциональных заказчиков т.к. предприятие новое и идет набор персонала, который закончится к 1 декабря.
Руководитель предприятия благосклонно и с пониманием относится к Вашей компании.
Задача:
К 31 декабря закрыть проект (на документах).
Начать промышленную эксплуатацию не позднее 1 августа следующего года.
РЕШЕНИЕ БИЗНЕС-КЕЙСА
К 31 декабря готовим «формальную» систему с «формальной» документацией. При этом делаем минимум трудозатраты на программирование и интеграцию. Это необходимо что бы качественно закрыть проект без претензий со стороны надзорных органов т.к. вполне возможно Заказчику потребуется предъявить доказательства целенаправленного расходования бюджетных средств. Также необходимо до 1 декабря подготовить и согласовать всю «формальную» документацию по проекту (нужен запас времени 1 месяц) что бы выполнить все бюрократические шаги, а 31 декабря выйти с чистой совестью на новогодний отдых.
Паралельно с формальной сдачей проекта будут вестись работы по подготовке реальной системы.
Черновой вариант плана реальной работы:
С 1 декабря (или раньше по факту появления функциональных заказчиков) начинаем параллельную работу по сбору требований (этап Анализа). Необходимо получить четкие управленческие договоренности о соблюдении сроков. Не позднее 1 февраля заканчивается этап анализа. К окончанию этого этапа необходимо иметь документ максимально четко описывающий реальную систему.
1 февраля – 1 апреля: готовим прототип.
1 апреля – 1 июня: делаем разработку.
1 июня – 1 июля: ОПЭ.
1 июня – 1 августа: ввод в ПЭ.
Далее я предлагаю обсудить проблемы с которыми можно столкнуться в процессе реализации проекта в рамках этого решения. Жду Ваши комментарии, а также другие варианты решения этого бизнес-кейса.
Вот вариант на тему сроков, качества и стоиомсти от студии Артемия Лебедева ( www.design.ru ):
Лично мое мнение - хорошо и дешево, а тем более быстро не сделаешь, но вот подобное заявление размещать на сайте я бы не стал.
Я очень люблю пресейл за то, что это дает возможность общаться с интересными и умными людьми. В процессе общения можно научиться очень многому, узнать больше о рынке, поймать интересные идеи, а также услышать противоположную точку зрения. Пусть пресейл не заканчивается моментальной продажей, главное уметь получить нечто более ценное – опыт.
Вчера был на замечательном пресейле. Моим оппонентом был директор проектной (многопрофильной строительной) компании Владимир Иванович. Очень интересный человек, образованный, бывший военный, а сейчас вполне успешный бизнесмен, который сумел преодолеть сложное время кризиса (особенно сложное для строительного бизнеса, в котором он работает).
Мы общались несколько часов. Это была интереснейшая дискуссия о бизнесе и жизни. Наше общение началось с того, что Владимир Иванович дал для ознакомления регламент деятельности его компании. В этом небольшом документе (страниц на 50) очень сжато, понятно описана вся деятельность компании без лишних слов. Я был приятно поражен т.к. очень редко встречаешь подобные документы у Заказчиков в России. Этот документ сразу дал понимание того, каким образом можно построить хорошую архитектуру решения без лишних трудозатрат.
В процессе общения оказалось что у нас одни и те же интересы в т.ч. книжные. Мы с удовольствием обсудили несколько книг и заложенные в них идеи. Он порекомендовал мне несколько книг, которые я с удовольствием пролистал и теперь хочу прочесть: Юрий Мороз «Пособие для Гениев», Олег Шрамко «Книга о богатстве», Герберт Н. Кэссон «Искусство делать деньги». Как только прочту эти книги оставлю здесь свои впечатления.
Одной из очень интересных книг, которые мы обсудили, был Воинский Устав. Я всегда считал что этот документ является основой менеджмента, а Владимир Иванович лишний раз это подтвердил, показав интересные выдержки из описания деятельности командного состава (если заменить слова «в боевой обстановке» на «в бизнес окружении» получится очень хороший учебник для бизнеса). Фактически Устав является консистенцией жизненного менеджерского опыта, обобщённого в одном документе.
В конце нашей дискуссии Владимир Иванович сказал интересную фразу: «Все мы любим продавать и зарабатывать деньги, но мы не любим когда нам продают и втюхивают». Сказав это он пояснил, что пресейл ему очень понравился т.к. он не ощутил этого самого «втюхивания» и общение получилось очень интересное, что дает возможности для дальнейшего диалога. В процессе нашего диалога я получил очень много полезной информации и сформирвоал много интересных мыслей. Желаю Владимиру Ивановичу и его профессиональной команде успехов в бизнесе и надеюсь на скорое продолжение этой интересной дискуссии.
Дальше за этим проектом я наблюдал со стороны. По началу все было хорошо. Прототип был реализован быстро, заказчик визуально доволен, но когда дело дошло до ОПЭ, что то случилось. Заказчику понадобились доработки, а ресурс консультанта, который был выделен на 2 недели, закончился. Соответствующие последствия проявились, как показывает практика, достаточно быстро. А в чем причина?
Основные идеи Agile:
• Личности и их взаимодействия важнее, чем процессы и инструменты;
• Работающее программное обеспечение важнее, чем полная документация;
• Сотрудничество с заказчиком важнее, чем контрактные обязательства;
• Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto:
• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
• приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
• частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
• проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
• работающее ПО — лучший измеритель прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
• постоянное внимание на улучшение технического мастерства и удобный дизайн;
• простота — искусство НЕ делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам.
Так в чем же причины провала этой методологии на проекте:
• Заказчик и Исполнитель не были знакомы с методологией внедрения. Эта методология, в очень поверхностном описании, была навязана новым руководителем группы проектов.
• Члены проектной команды не были замотивированы на использование этой методологии.
• Явным образом были нарушены коммуникаций. Была закрыта возможность прямого взаимодействия Заказчика и Исполнителя (в силу занятости и статусности сотрудников Заказчика).
• Некорректная оценка сроков проекта, диктуемая желанием угодить интересам Заказчика.
• Недостаточная само организованность участников проектной команды.
• Недостаточное кол-во и объем выделенных ресурсов.
В итоге, Agile это ЗЛО?
Мне кажется, эта методология не ЗЛО и может очень хорошо проявить себя на небольших проектах и позволить быстро добиться результатов без лишней бюрократии. Основные факторы, которые способствуют успеху:
• Принятие и понимание обоих сторон проекта этой методологии.
• Обеспечение максимально полной информацией участников проектной команды. На момент старта проекта все участники должны четко понимать что они создают.
• Большое внимание на коммуникации, обеспечение прямых и непрерывных коммуникаций.
• Наличие буфера ресурсов на случай более длительной работы на проекте.
• Правильная мотивация проектной команды, ориентированная на быстрый результат.
• После сдачи проекта – обязательное документирование результатов.
Правильно составленные рамки проекта – клетка, в которой сидит заказчик во время разработки. Я уверен, что Вам не хочется, что бы злой и голодный Лев вырвался на свободу и скушал Вас со всеми потрохами, поэтому будьте очень внимательны, когда формируете эти самые рамки.
В ряде случаев Рамки проекта спасали реализацию всего проекта в конфликтных ситуациях, поэтому формирование этого документа очень важно на этапах Диагностики и Анализа.
Рамки должны быть комфортны для обеих сторон. Не забывайте, кто платит деньги. При этом нельзя позволять загонять себя в угол (оказаться в той же клетке) нереальными условиями. Интересы обоих сторон должны быть четко сбалансированы.
Часто возникает соблазн спрятать за Рамки проекта части системы, которые «неудобны» по тем или иным причинам. Как говориться «оно всплывает». Лучше проговорить с заказчиком и четко описать, какие части системы не будут реализованы в данном проекте, а реализация каких блоков может привести к увеличению трудозатрат. Такая честность может позволить избежать конфликтов, а также дополнительно заработать деньги на будущем развитии системы.
Итак, основные компоненты рамок:
Функциональные требования
Описание функциональных требований должно содержать полный перечень задач, решаемых системой:
• Описание создаваемой системы.
• Функции системы, подлежащие реализации.
• Перечень отчетов и печатных форм.
• Описание бизнес-процессов, подлежащих автоматизации.
Нефункциональные требования
Нефункциональные требования определяют технические требования к проекту:
• Требования к безопасности.
• Требования к платформе.
• Производительность решения.
• Масштабируемость.
• Интегрируемые системы.
• Доступность и отказоустойчивость.
Логические рамки
Логические рамки определяют каким образом будет происходить создание системы:
• Что именно настраивается или создается (например, система реализуется на базе MS Dynamics CRM).
• Что и в какие сроки Заказчик должен предоставить Исполнителю для реализации работы (приказы, положения, описания существующих систем, доступ к инфраструктуре и т.д.).
• Настройка инфраструктуры описывает - кто отвечает, что именно разворачивается.
• Условия доступа представителей Исполнителя к инфраструктуре Заказчика (удаленный доступ к серверам) и возможности этого доступа (VPN, открытый буфер обмена и т.д.).
Географические рамки
Определяется где физически будут производится работы, а также возможность работы в офисе заказчика и обеспечение пропуска сотрудников и рабочих мест. Также необходимо определить режим работы офиса заказчика, в случае если там предполагается работа.
Временные рамки
• Общая длительность проекта.
• Дата начала и срок окончания проекта.
• Ключевые вехи проекта (что именно и когда).
Задачи не входящие в рамки проекта
Очень важно вывести серьезные задачи, не подлежащие автоматизации, но при этом существующие на горизонте:
• Описание функционала, не подлежащего реализации.
• Описание внешних систем с которыми не будет производиться интеграция.
• Описание действий и работ, которые Исполнитель не будет совершать в рамках данного проекта.
Допущения
В данном разделе можно указать допуски, которые могут применяться к результатам проекта.
Прочие условия
В этом разделе фиксируются прочие ограничения, не вошедшие в другие разделы:
• Ответственность Заказчика за использование Решения в рамках рекомендованной инфраструктуры.
• Явные ограничения системы (например, CRM система не отвечает за планирование товародвижения).
• Действия, которые не могут быть автоматизированы и подлежат выполнению вручную.
Давно хотел раскрыть тему методологии. Говоря про методологию я говорю о Sure Step. При этом, коллеги, без фанатизма. Практика показала, что классическим Sure Step пользоваться крайне сложно. Можно воспринимать эту методологию как вектор движения и адаптировать ее под свои нужды.
Недавно на одном из проектов столкнулся с тем, что Консалтинговая компания, привлекшая меня на проект, намеренно игнорировала необходимость двигаться по этапам проекта в рамках методологии, обосновывая это необходимостью быстрого внедрения без «лишней бюрократии». Сразу скажу, что я быстро перестал сотрудничать с этой компанией т.к. подобные большие проекты в подобной ситуации обречены на провал в 100% случаев, а перейти на рельсы методологии данная компания решительно отказалась. История этого внедрения, насколько я знаю, закончилась ожидаемым провалом и отказом заказчика от дальнейшего сотрудничества. Урок этой истории поучителен. Используйте методологию, не двигайтесь на следующий этап не закрыв предыдущий, а также учтите, быстрых проектов не бывает.
Ниже приведены основные этапы в определенной последовательности. Менять местами этапы проекта бессмысленно также как и совмещать.
Типичные проблемы, ошибки и недочеты
Многие консультанты пытаются смешать Этап диагностики и этап Анализа. Запомните – диагностика до договора, а анализ после. Нельзя подписать договор не понимая рамок проекта и объемов работ.
Зачастую Консультанты на этапе Диагностики и Анализа не обращают внимание на отчеты и печатные формы. Моя практика показала, внимательное изучение этих документов всегда положительным образом влияет на реализацию проекта. Заказчик зачастую умалчивает о важных моментах, таких как ABC классификация или типизация сделок. Ради формирования этих документов и делается система, не забывайте это.
Жесткие договорные условия (сроки, рамки, риски). Коллеги, сроки несмотря ни на что – не предсказуемы, рамки гибки, риски есть и будут всегда. Оставляйте в договорах возможности для маневра.
Совмещать этап Дизайна и этап Разработки категорически нельзя! На этапе дизайна формируется образ системы, ее внешний вид для заказчика. Максимум – скрипты для работы форм. На этом этапе у Заказчика открываются глаза. Вы сразу же узнаете, что интервьюирование на первых этапах работы дало максимум 50% реальной информации. Именно на этом этапе ВСЕГДА меняются рамки проекта. Прототип это как первая примерка, все должно быть готово к немедленной переделке. В случае, если в Решении появился тяжелый код, вы получите гарантированное увеличение трудозатрат.
Опытная эксплуатация воспринимается заказчиком, как тестирование уже готового решения. Сразу же согласуйте с Заказчиком, что это не так! На этом этапе решение окончательно настраивается под нужды заказчика, что также может влиять на рамки, сроки и трудозатраты (которые заказчик должен оплатить).
Нельзя пускать в тестовую среду всех пользователей Заказчика. Только ключевые пользователи, участвующие в рабочей группе внедрения должны тестировать решение. Причина – на этапе тестирования будут баги и недочеты, которые отпугнут простых пользователей от дальнейшей работы с Решением.
Итак, сам процесс
Диагностика
Анализ потребностей
Оценка инфраструктуры
Определение рамок проекта, объемов работы и бюджета
Подготовка предложения
Принятие решения о начале внедрения
Анализ
Детальный анализ бизнес-процессов
Детализация требований
Подготовка описания дизайна решения
Подготовка детализированного плана работы
Дизайн
Разработка прототипа
Дополнительная проработка требований
Подготовка технического задания
Разработка
Разработка решения (программные компоненты)
Разработка интеграции с внешними ИС
Разработка бизнес-процессов
Разработка отчетов и печатных форм
Разработка программы испытаний
Опытная эксплуатация
Проведение испытаний, нагрузочного тестирования
Отладка решения
Миграция данных
Обучение ключевых пользователей
Подготовка к промышленной эксплуатации
Разработка пользовательских инструкций
Приемка заказчиком
Промышленная эксплуатация
Перенос решения в рабочую среду
Начало эксплуатации
Поддержка в ходе эксплуатации
Обучение пользователей
