Задумывая автоматизацию вопрос, клиент ищет ответы на следующие вопросы:
Чтобы подрядчика выбирать осознанно и объективно, нужно владеть информацией в достаточном количестве для принятия решения. В условиях же неопределенности, риск ошибки возрастает.
Решение: провести экспресс обследование, и в краткие сроки получить описание и анализ проекта достаточный для оценки сроков и бюджета.
Содержание:
Всем привет! С вами Зосим Максим и команда TQM systems.
Как говорится семь раз отмерь, один отрежь и это непосредственно касается предпроектной работы с заказчиком. Именно об этом мы сегодня и поговорим.
0:18 Для чего вообще нужно проводить какое-то обследование?
Наверняка первым возникает вопрос: для чего вообще нужно проводить какое-то обследование? Когда клиенту необходимо автоматизировать процессы или улучшить их - он формирует волнующие вопросы. Такие как: сколько будет стоить проект, из чего состоять, что нужно для этого сделать и тому подобное. В формате «необходимо» и направляет нам запрос с просьбой оценить эти услуги в финансовом эквиваленте.
0:43 Пример: как пишет заказчик и то, как это разнообразно можно трактовать.
И вот вам небольшой пример заказчик пишет: нужна реализация платежного календаря. Что под этим подразумевают заказчик? Реализовать эту задачу можно по-разному. В Управлінні торговим підприємством, типовыми средствами занести заказы и платежки - это вложится в несколько часов работы. А если подразумевается что в календаре нужно, например, бюджетирование, лимиты или удовлетворения и контроль этих лимитов - их УТП совсем нет. Нужно или реализовывать дополнительно. Работать и аналитику, и программистам - а это может не уложиться и в 160 часов. Или выбирать другой программный продукт, к примеру, ERP, в котором есть такой функционал. Но стоит он на порядок дороже. И если другие функции из ERP не нужны, если смысл приобретать дорогую и сложную конфигурацию? В итоге примерная оценка времени на реализацию от 3 до 160 часов. Можно ли при таких водных рассчитать цену реализации соответствующую действительности? В данном примере, на этапе экспресс обследования, клиенту задается вопрос: что Вы хотите видеть в платежном календаре? Ответ клиента - оценка задачи. Нужно собрать в календаре все неоплаченные заказы наших клиентов - оценка будет от 16 до 24 часов. Хотим собрать заказы поставщиков, покупателей, приход денег, увидеть кассовый разрыв, отображать кредиты и их погашение и еще какие-либо функции - от 32 до 240 часов. Первое, что нужно понимать по каждому из требований, в зависимости от уровня детализации: стоимость реализации может разница в десятки раз, что влияет на оценку всего проекта в целом.
2:21 Концептуальные вопросы для предварительной адекватной оценки
Чтобы дать адекватную оценку, даже приблизительно, изначально мы проводим экспресс-обследования. А именно: проводим предварительный сбор информации о бизнесе, анализируя ее и формируем первичную рекомендацию. В целом мы отвечаем на концептуальные вопросы такие так:
2:53 Что определяем в ходе обследования
Также на основе полученной информации определяем:
3:28 9 этапов предпроектного экспресс обследования
Если говорить детально, то условно, предпроектное экспресс обследование мы делим на 9 этапов. Рассмотрим подробней.
3:36 Интервью ключевых специалистов
На первом этапе экспертным консультантом проводится опрос интервью ключевых специалистов. Бизнес-функции руководителей, при необходимости осматриваются имеющиеся системы, рабочие места, производства, склады, помещения. На этом этапе важно узнать обо всех ключевых требованиях и проблемах. Это даст нам понимание картины в целом. Поможет определить оптимальные пути решения задач. Сроки проведения первого этапа зависит от количества необходимых интервью.
Небольшой лайфхак - во время интервью не задавайте глупых вопросов. Записывайте всё на аудио, что касается проекта, чтобы не упустить детали. Детализируйте непонятные моменты - они могут повлиять на принятие некоторых решений и на бюджет, в том числе.
4:20 Второй этап - формализация требований.
Второй этап - формализация требований. По результатам интервью и предоставленной документации, в обязательном порядке составляется первый драфт отчета экспресс-обследования. Этот документ консолидирует все те знания, которые вы получили от заказчика. Первая версия со слов интервьюируемых.
4:37 Что содержится в отчете на втором этапе
Отчет содержит:
Важным элементом при сборе требований, которые иногда забывается является: важность и приоритезация задач. По ходу составления аналитиком такого документа - могут уточняться вопросы и альтернативные решения, чтобы зафиксировать приоритеты и степень первоочередности задач.
5:04 Анализ и формализация расхождений
Этап третий - анализ и формализация расхождений. Задачи данного этапа:
Все выявленные варианты решения мы обсуждаем с заказчиком и предлагаем уточнение к требованиям в документе (отчет экспресс-обследования).
Определение важности и первоочередности - это четвертый этап. Нужно и важно правильно доносить заказчику мысль, о том что экспресс-обследование - это часть которая дает какой-то взгляд на то каким может быть проект. На этом этапе, все требования заказчика, мы делаем в виде списков функциональных требований верхнего уровня. Отдельные требования по бизнес-процессам могут состоять из целого ряда различных функций. Определяется их очередность и важность, с точки зрения влияния на системы в целом. Преобразование проводит специалист исходя из стандартов и опыта решения аналогичных задач. Задача является основной для дальнейшей оценки выбора технической реализации платформы и разработки технического задания. И внимание: в дальнейшем список функций детализируется при составлении документов функциональных требований и технического задания, которые не входят в область работ экспресс-обследования. Время затраченное на анализ на напрямую зависит от функциональных требований.
6:38 Выбираем технологическую платформу
Следующий этап – подбор технологических платформ и вариантов. По укрупненному списку функции специалист составляет матрицу-соответствие потенциально пригодных решений, а также вариантов подходов к реализации проекта. Технологически подходящие, готовые и адаптивные решения мы оцениваем по списку предоставленных в них функций и настраиваемых возможностей. После этого мы можем увидеть предварительный объем необходимых доработок. На основе матрицы, наиболее рациональные варианты, выбираются для оценивания. Также возможны варианты подбора нескольких решений, интегрированных в один комплекс.
Шестой пункт - экспертная оценка бюджетов. После выбора вариантов базовых платформ для автоматизации, мы проводим экспертную оценку. Как это происходит – по укрупненному списку требований-разрывов выстраивается оценка необходимого времени на реализацию каждого блока. Метод трехточечной оценки в описании и ссылочка будет где-то тут >>>
Узнать подробно как рассчитывается бюджет проекта методом трехточечной оценки можно в нашем видео:
Как обеспечить успех проекта. Цена компетентности. Методология оценки проектов >>>
Оценка выставляется в часах исходя из предположения, что работы будут выполняться специалистам среднего уровня. В дальнейшем будут некоторые отклонения в обе стороны в зависимости от класса привлекаемых в дальнейшем специалистов и подрядчиков. Оценку мы проводим по каждому выбранному потенциальному варианту реализации отдельно. Поскольку и реализации отдельных задач в разных системах может значительно отличаться. Итоговая цифра трудоемкости является дополнительным критерием отсеивания решения или определения оптимального пути.
Также мы проводим предварительную подготовку бюджета. По предварительно отобранным вариантом реализации мы составляем смету всех необходимых затрат на оборудование, программное обеспечение, количество необходимых клиентских лицензий по видам. Необходимые дальнейшие этапы проекта в разрезе функциональных блоков - функциональные требования, техническое задание и разработка, рекомендуемое количество времени на стандартное внедрение и обучение. Итоговую оценку работ рассчитываем в рабочих днях - это обосновывает количество выделяемой специалистов зависимости от желаемого срока реализации. Сравнительный бюджет предварительно демонстрируем заказчику с комментариями. Возможны уточнения и корректировки.
8:47 Выявляем риски и оцениваем их
Следующий этап - анализ и формализация рисков. На этом этапе, исходя из реалий, мы составляем список рисков, которые могут повлиять на ход проекта как технических, так и организационных или даже политических - изменения в правовом поле, например. Указываем степень возможного влияния риска на проект, приводим рекомендации по предотвращению или минимизацию рисков. Рекомендации базируются на опыте и также опираются на практику с различными исходами, как успешные, так и провальные.
9:16 Основной документ экспресс-обследования
Подготовка итоговых выводов - так звучит восьмой этап. На этом на этом этапе мы предоставляем основной документ экспресс-обследования. Представляет он собой описание всех выводов по каждому из этапов обследования. Содержит:
Ознакомившись с отчетом у клиентов, всегда найдется парочка вопросов-уточнений - не отказывайте ему этом удовольствии.
10:00 Обсуждение полученных результатов
Девятый и заключительный этап - презентация решения. На основании проведенных работ наши ключевые специалисты, работающие на обследование, готовят презентацию и предоставляют заказчику. На презентации озвучивается важные моменты выбора, акцентируется внимание на рисках и уточняются озвученные в ходе презентации вопросы представителей заказчика. Также обсуждаются варианты дальнейших необходимых этапов проекта и возможные сроки реализации. А также критерии выбора подрядчиков для реализации. Кстати, отчет экспресс-обследования может служить документом для проведения публичного тендера. Предоставив отчет, который определяет целостность и варианты внедрения нового продукта - клиент определяется с оптимальным на текущий момент для бизнеса вариантами решений и составляет план дальнейших действий, где определяется:
11:06 Главное: что дает результат экспресс-обследования
В целом отчет экспресс-обследования становится отправной точкой для всего проекта. Такой документ, если он составлен до старта работ, дает возможность выбрать:
По результатам экспресс обследования мы проводим оценку всего проекта или его отдельных задач.
11:33 Трехточечная оценка - методика оценки проектов
В своей работе мы используем трёхточечную оценку. Кстати, есть об этом отдельное видео и ссылка будет в описании и в правом углу.
Обследуйте, анализируйте и работайте с выгодой. Не забываем подписываться на канал и ставить колокольчик.
Важность такой подготовки к проекту ощущают прежде всего руководители бизнеса, и проектов, потому как только результаты компетентного экспресс анализа дают достаточно информации для оценки и принятия решения по проекту: какие цели автоматизации, конкретные задачи, какие способы их реализации нужны. На основании этих данных можно будет рассчитать реалистичную оценку бюджета проекта.
Когда в организации назревает необходимость в автоматизации или ее улучшении, обычно директор принимает решение: изменения нужны! И поручает реализовывать эту задачу своим подчиненным, в идеале это руководитель ИТ, но на практике к нам обращаются специалисты разных компетенций: системный администратор, менеджер по продажам, менеджер по закупкам, HR и даже сам руководитель.
В компанию они направляют запрос с просьбой оценить в деньгах автоматизацию объекта и прилагают описание на 1-3 листа в формате: Хотим… Хотим систему кадрового учета, хотим отслеживать движение товаров… Хотим Казначейство.
Первое, что нужно понимать, по каждому из таких пунктов “Хотим” в зависимости от уровня детализации (функций и возможностей которые нужны) стоимость реализации может разнится в 10-ки раз. и соответственно стоимость всего проекта можно оценить с такой же точностью.
Пример:
Например заказчик пишет: Нужна реализация платежного календаря. Что под этим пожеланием заказчик подразумевает? Реализовывать эту задачу можно по разному: в УТП типовыми средствами завести заказы и платежки - это вложится в несколько часов работы. А если подразумевается, что в календаре нужно, например, бюджетирование и лимиты - их в УТП совсем нет, поэтому нужно или реализовывать дополнительно, работать и аналитику и программистам, а это может не уложится и в 160 часов. Или выбирать другой программный продукт ERP - в нем есть такие функции, но стоит он на порядок дороже (180 тыс грн вместо 16) и если другие функции из ERP не нужны, есть ли смысл приобретать дорогую и сложную конфигурацию.
В итоге примерная оценка времени на реализацию 3-160 рабочих часов - можно ли при таких вводных рассчитать цену реализации, соответствующую действительности. Экспресс анализ позволяет снять такую вилку и четко описать требования клиента. На их основании клиент и сам поймет на что он может рассчитывать, а что нужно пересмотреть, и при этом весь объем работ будет ясен.
В этом примере на этапе экспресс обследования клиенту задается вопрос: что вы хотите видеть в платежном календаре?
| Ответ клиента | Оценка задачи |
|---|---|
| нужно собрать в календаре все неоплаченные заказы наших клиентов | 16-24 часов |
| хотим собрать заказы поставщиков, покупателей, приход денег, увидеть кассовый разрыв, отображать кредиты и их погашение, и еще… | 32-240 часов |
Дальше проводится уточнение всего заказанного. Но без анализа каждый пункт требований клиента можно оценить только очень приблизительно.
Чтобы дать адекватную оценку даже приблизительно и первоначально нужно провести экспресс обследование и составить спецификацию проекта в которой в общих чертах будет указано видение (что нужно и зачем), пути реализации способы и инструменты.
Узнать подробно как рассчитывается бюджет проекта методом трехточечной оценки можно в нашем видео:
Как обеспечить успех проекта. Цена компетентности. Методология оценки проектов >>>
В подавляющем большинстве случаев предприятия не каждый день проводят проекты автоматизации, и наработанных процедур, проверенных партнеров и консультантов в ИТ сфере не имеют. Поэтому самым логичным подходом выдается собрать все предложения и выбрать из них лучшее.
В качестве основы для предложения составляется 2-3 страницы описания из общих и емких фраз, которые можно толковать как угодно. Такое описание выходит на рынок и рассылает в разные компании.
Главное, что хочет на этом этапе получить предприятие - это цифра стоимости. В итоге ему поступают десятки различных предложений стоимость которых отличается в разы.
Дальше у клиента складывается впечатление, что часть подрядчиков сильно завышают цену, и выбирает тех, кто предлагает дешевле, полагая, что эта цена за набор одних и тех же функций.
Но на практике дешевая цена может означать:
Для себя руководитель проекта может понять трудозатраты подрядчика в часах, потому как стоимость.
Если трудозатраты в часах все подрядчики выставили примерно одинаково: значит оценка по вашему проекту примерно однозначная, но это тоже не факт, вам ведь не понятно: на какие работы и задачи пойдут эти часы.
Поэтому и выбрать лучшего подрядчика опираясь на ценовое предложение составленное по свободному описанию крайне опасно. Поскольку разница в понимании описания заказчиком и подрядчиком может кардинально отличатся.
Пример:
К нам обратилась компания Х за помощью с просьбой найти выход из тупиковой для них ситуации: по описанию своего проекта, который они разослали подрядчикам. В ответ получили предложения в диапазоне от 6000 у.е. и до 60 000 у.е. - разница в цене колоссальная и здравомыслящее руководство понимает, что едва ли вопрос в жадности некоторых подрядчиков. Проблема в том, что в минимальном ценовом предложении функциональность может быть представлена минимально и не охватит нужд заказчика. А верхняя планка - это большая цена, и клиент хочет понять есть ли необходимость ее платить. В условиях неопределенности причин таких ценовых расхождений принять решение оказалось просто невозможным.
Для этого клиента мы провели экспресс обследование и составили отчет, в который как часть методологии оценки вошла спецификация проекта - детализированное описание требований к системе и способов их реализации. На ее основании рассчитаны конкретные затраты на реализацию проекта 22 000 у.е, анализ обошелся в 1 150 у.е. На выходе компания получила документ с результатами анализа бизнес процессов и квалифицированно описанными требованиями - что позволило определить вектор дальнейшего движения и принять решение.
Такая оценка позволяет оценить бюджет проекта с точностью 70-80%. Для более точной оценки и для сложных проектов потребуется еще два этапа: это описание функциональных требований (ФТ) и техническое задание (ТЗ).
Гораздо надежнее, когда у вас есть отчет и анализ с оценкой в рамках спецификации требований.
С этим документом компания может рассчитывать на реальную оценку своих требований в деньгах и проводить тендер. Когда финансовая оценка интерпретируется подрядчиками однозначно, подбирая партнера для проекта уже можно обратить внимание на его возможности и профессионализм в работе, на наличие достаточных ресурсов для проекта, да и в принципе на сходимость с командой или условиям договора.
Получая максимально точную оценку, клиенты склонны впадать в другую крайность, под названием “фикс прайса”, когда настаивают на жесткой фиксации суммы проекта. Это необдуманная попытка себя обезопасить от “не порядочности” подрядчика. Она приводит к потере возможности гибкой разработки: по ходу внедрения, может возникнуть желание или необходимость настроить что-то иначе, открываются дополнительные возможности оптимизации, но нужно дополнительное время работы, а цена зафиксирована. Это приводит к напряженным отношениям на проекте, и даже конфликтам. Мы с таким требованием не работаем.
Хочу еще добавить касательно цены для любителей “подешевле”. Цена может быть уменьшена либо за счет объема работ, либо за счет качества их выполнения.
Ни один подрядчик не будет работать над проектом в убыток себе. Ему нужно оплачивать как минимум программистов и аналитиков. И если заявленной стоимости хватит только на половину проекта, подрядчик просто может остановить свои работы, в результате чего судьба проекта станет неопределенной.
Компания может предлагать хорошую цену за счет качественной организации процессов по проекту, если использует методы и стандарты эффективной работы. Или немного сокращать время реализации задач за счет уже наработанного опыта. Но индивидуальная трудоемкость процесса зависит от его задач к реализации.
Для больших проектов делаются скидки по причине длительной вовлеченности персонала в проект - нужно меньше времени на переключение между задачами.
Так вот если предлагают цену в разы меньше - что это значит.
Те кто работал с программным кодом знает - что такое хороший код, а что такое эконом вариант, где не тратится время на “лишнее”:
В принципе такой код может работать и не вызывать проблем при условии что вы не собираетесь:
Но если что-то из этого понадобится, то в каждом из трех вариантов будут дополнительные затраты времени, чтобы разобраться с кодом не упорядоченным по стандартам.
Особенно высокая вероятность проблем при обновлении, которые, например 1С:Підприємство выпускает регулярно. Дело в том, что дополнительные доработки должны быть оформлены по определенному стандарту, иначе, они будут считаться частью стандартной конфигурации и будут удалены при замене на новый блок кода при обновлении автоматически. и все доработки можно элементарно потерять. Или же нужно провести сравнение кода и выделить измененные области, а это немало времени.
Важно в начале проекта определить концепцию - на основе каких систем автоматизации будет решаться задача.
Детали по ходу проекта можно менять, а вот выбор базовой технологии, нужно сделать безошибочно иначе есть риск попасть в ловушку недостаточной технологии.
Если оценка проведена по минимальному варианту базового ПО, может настать момент, что его функций не хватит на все всплывающие позже необходимости бизнеса.
И придется начинать заново на другой платформе, а деньги и время потрачено.
Например:
По предварительному описанию заказчика похоже что будет достаточно базового продукта 1С:Підприємство УТП - плюс доработки.
Хороший бюджет клиенту все нравится приступает к внедрению. Но год спустя, после введения в эксплуатацию оказывается, что хотели не так, не ложится на бизнес процессы, персоналу не хватает функций, не учитывается производство, нет управления, и анализа, а онлайн кабинет вообще нет возможности реализовать - технология не та. и т.д.
Заказчик берется за голову.
Выявилось, что выбранную платформу доразвить до нужного уровня не получится. Теперь можно купить еще и ERP попробовать реализовать на ней, а это бюджет и все начинать сначала.
А вот в начале проекта у заказчика был выбор: провести к примеру тщательный анализ, который бы показал, что на все требования нужна ERP плюс внедрение и минимальные доработки.
Сумма конечно больше первой, но зато исключается риск, несоответствия, перевнедрения, потери времени впоследствии, и понятен ресурс развития.
Экспресс анализ относится к компетенциям бизнес аналитика, он может быть:
Давайте разберем какой вариант лучше.
Бизнес консультант из консалтинговой организации стоит примерно как и консультант разработчика, но решает несколько иную задачу . Бесспорно он отлично разбирается в бизнес процессах. Только есть важный вопрос насколько подробно он разбирается в особенностях ИТ отдельных технологий продуктов и внедрений, скорее ему придется работать совместно в тандеме с таким специалистом.
У внутреннего специалиста заказчика, часто встречается эффект “замыленного глаза”, когда постоянно разбираясь во внутренних процессах он теряет способность видеть их под другим углом, и генерировать свежие решения.
Можно нанять дополнительного эксперта. Но на практике это редкие случаи. Поскольку проект - это временное мероприятие для достижения определенных целей, направленное на создание уникального результата (PMBOK). Как следствие такой сотрудник на постоянной основе не нужен, а если вы возьмете специалиста с прицелом его уволить, то можно догадаться куда зайдет ваш проект. Не проще ли на время проекта, заказать эти услуги у подрядчика.
Подрядчик это самый оптимальный вариант, и совсем не нужно связываться договором на разработку и внедрение на стадии анализа. Достаточно договора на проведение анализа, по итогам которого можно пользоваться результатами по своему усмотрению.
Может быть и так - анализ показывает, что в случае конкретного бизнеса определенная платформа не подходит для решения задачи и есть более подходящие решения от других вендоров, их на рынке много: 1С:Підприємство, Odoo, Terrasoft, или др. но часто подрядчики не в состоянии давать такие рекомендации из-за структуры своего бизнеса в которой есть менеджеры по продажам с планом на конкретные продукты. Часто этим грешат именитые партнеры, заточенные под продажу исключительно партнерских решений, они хорошо и глубоко вникли в подробности отдельных продуктов и им не хочется рекомендовать другие, может более подходящие решения..
Например:
С начала 2018 официально объявлено что Управління виробничим підприємством (УВП) уже снято с продаж, а значит, что и на долголетнюю перспективу сопровождения рассчитывать сложно. Но решения на УВП по прежнему на рынке предлагаются и продаются. Потому что этот продукт хорошо известен подрядчикам, есть наработки и опыт и не хочется двигаться из зоны комфорта.
А что значит для Заказчика начинать проект на заведомо устаревшей технологии? Через год - два, все сначала?
Сегодня на рынок вышла платформа BAS со своими крупными решениями, такими как ERP и Управління холдингом. Системы построены на новой технологической платформе, и учитывают современные методики работы и мобильные технологии. В дальнейшем на этой платформе планируется выход и продуктов для среднего и отраслевого бизнеса. Продукты BAS ориентированы на украинский рынок.
Но этот продукт новый, специалистов по нему мало, а в подготовку и обучение нужно вкладываться.
Причем когда подрядчик привыкает к конвейерной работе с небольшими более менее стандартными проектами, он уже не так много внимания уделяет индивидуальному анализу, который крайне важен для крупных проектов. Он может навскидку определить во сколько обойдется проект как на 5 пользователей так и на 500.
Заказчику не стоит доверять такой быстрой оценке, даже если вообразить огромный опыт подрядчика. Как показывает мировая и местная практика - весь дьявол в деталях. И каждый третий проект без предварительного анализа заходит в тупик.
К нам обращается большое количество таких заказчиков, которые уже провалили первое внедрение “на глаз” и теперь готовы прибегнуть к полной процедуре поэтапного исправления ситуации. То, что они уже потеряли, во много раз больше стоимости экспресс анализа - это факт.
Документ “Отчет об экспресс обследовании” помогает определить сколько времени понадобится на составление спецификации требований. Потому что для более глубокого анализа нужно предварительно выяснить:
Исходя из этой информации можно получить первую спецификацию с точностью оценки 70-80%, и оценить сколько времени понадобится на ФТ и ТЗ.
Пример
На большом предприятии хотели решить задачу отслеживания миграции упаковок между разными системами учета: в бухгалтерии она ведется как одна номенклатура, а в ЕРП различается по цветам и партиям. На обсуждение способов решения потрачено порядка 100 часов переговоров. А в реальности цена вопроса 20 000 грн в год разницы по учету этикеток. То есть рентабельности решения таких вопросов нет. Такую задачу проще решить введя дополнительный бизнес процесс по регулярной инвентаризации и списанию.
Это такая ситуация, когда будет проводится углубленная автоматизация, вестись переговоры и тратиться деньги, а суммарно экономически расходы не покроются никогда.
Такие моменты начинают выявляться на этапе экспресс обследования, а на втором этапе в спецификации описывается: как каждое бизнес требование, конкретно решается, в конкретной системе. И система к этому моменту уже выбрана.
Но возможно построение спецификации и не понадобится. По результатам экспресс анализа можно четко дать рекомендацию: возможностей какой базовой системы будет достаточно для проекта - осваивайте ее и по итогам доработаем немного не охваченных требований.
Экспресс анализ не понадобится в случае, когда у заказчика есть человек с достаточным уровнем компетенций, чтобы провести анализ бизнеса своими силами. И запрос подрядчику уже направляется в виде подробного видения и спецификации. При этом он должен разбирался и в бизнес процессах, и в программах автоматизации, понимать технологию и состав конфигураций 1С:Підприємство и не только, знать стандарты составления проектной документации.
Не нужен анализ и для совсем простых проектов.
Пример
В достаточном для оценки виде запрос от заказчика должен выглядеть примерно так:
Хотим Казначейство :
Для чего нужно:
Добавить документ Заявка 1, поля: №, Дата, Заказ…..
Добавить оборотные регистры заявки 1, с одноименными полями...
Написать отчет по регистрации заявки с отбором по полям 1, 2, 3
… и так по каждой задаче.
Из такого описания видно, что специалисты заказчика прекрасно разбирается в архитектуре системы, и могут ее расписать по объектам, понимают чего хотят добиться и какие показатели им нужны на выходе, понимают источники, где исходные данные и как протекают процессы сейчас. Когда составляется новые требования описать проще, сложнее будет с описанием изменений уже существующего функционала.
Такой заказчик сделал экспресс анализ своего бизнеса самостоятельно, и в дополнительном нет нужды. Заказчик четко видит как он будет достигать свои бизнес цели, а подрядчика привлекает в качестве исполнителя разработки по требованиям.
По такому описанию напротив каждого пункта можно довольно четко определить объем работ и тогда суммарно посчитать трудоемкость всего проекта. И белых пятен, а соответственно и неопределенности по нему минимум.
Agille - популярная сегодня в мировой практике технология гибкой разработки. Цели и требования по ходу работы могут модифицироваться с учетом новой информации. Работа над проектом проводится в рамках постоянного взаимодействия заказчик-исполнитель для отслеживания достигнутых результатов, а соответственно их корректировки.
И даже для такой методики работы в начале лучше провести обследование: провести неделю с аналитиком, он соберет все бизнес цели, задачи, опишет чем пользуются сейчас, проанализирует текущее процессы и опишет потребности в изменениях, чтобы выстроить более четкую структуру дальнейших действий. И также наметить конечною цель.
Иначе бюджет может быть очень размытым, как и конечные цели.
Анализ на старте проекта решает боли как Заказчика так и подрядчика, потому что последний не тратит свое время на попытки уточнить и оценить более менее честно проект, поскольку действие практически бесполезное и его результаты могут только сбить с толку заказчика (описывалось выше). А обработка страницы требований заказчика стоит ни много ни мало, а 0,5 часа на страницу высококвалифицированного специалиста.
Клиент же за небольшую относительно цены проекта сумму получает гарантию правильного развития проекта.
Когда клиент определяется с подрядчиком, следующими этапами на пути к внедрению являются:
Для крупных проектов эти этапы обязательны. для небольших и понятных они могут проводится частями параллельно с внедрением на других участках.
По большим проектам клиенты запрашивают услугу моделирования - это особо актуально для сложных систем, таких как ERP.
Аудит в экспресс обследование не входит обычно, но по желанию заказчика может быть проведено как часть обследования. Применяется, когда у заказчиков есть требование из разряда "А вы можете посмотреть, что у нас в системах и сказать, что нам нужно сделать".
Есть 3 вида:
Подведем итог, чем клиенту помогает экспресс обследование:
Детальная информация по процессу - как проходит, что нужно, этапам, документам, итогам, на странице нашего продукта экспресс-обследование проектов.
Индивидуальную консультацию вы можете получить у наших специалистов. Обращайтесь, консультируйтесь!
Видео о ключевых моментах внедрения систем автоматизации на канале TQM systems: кейсы, методики работы, параметры выбора, новые разработки и возможности.
SaaS сервисы
Программы 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизация
Аудит IT проектов
Интеграция 1С:Підприємство
Получайте наши информационные материалы:
Работаем на IT-рынке с 2008 года.
Наша миссия - упростить управление данными.
Copyright © 2008-2024 TQMsystems. Все права защищены. Privacy Policy | Terms of Service