KoderLine
Обслуживание
и внедрение
Наш Facebook Наш Instagram Наш YouTube
+7 (495) 374 55 29 Обратный звонок
Для чего нужно моделирование?

Для чего нужно моделирование?

1
1408
04.08.2016 Дмитрий Шатохин
 

Классическая ситуация: Заказчик дает вводные данные и ждет от нас оценку проекта. Часто присылает документ, гордо именуемый «Техническое задание». Иногда, впрочем, это действительно Техническое задание. Только в большинстве случаев даже адекватный входной документ никоим образом не гарантирует адекватную оценку от потенциального подрядчика.

Почему подрядчик не может дать точную оценку проекта, если есть полноценное Техническое задание? 
 
     
  Если бы каждая конкретная фирма с конкретным финансовым директором или ИТ-директором не были уникальны вне зависимости от сферы деятельности, а любые, кроме совсем уже общепринятых, операции не делались как удобно начальству\как сложилось исторически – то да, ТЗ было бы достаточно. Но каждый раз, когда после ознакомления с документацией наши спецы начинают задавать вопросы, выясняется море нюансов, которых за день не зафиксируешь. И это если у нас намечается проект по какому-то одному контуру. А если их несколько?   
     
 
Могут возразить – дайте оценку сразу, вы же опытные, вы всякое видели. Все верно. Только если специалист будет оценивать сразу, он заложит все мыслимые риски, вспомнит всех самых проблемных своих клиентов и проекты, и накинет еще процентов 20 сверху, чтобы гарантированно не работать бесплатно, и не воевать под конец с Заказчиком, выбивая у него доп. финансирование.
 
 

Отсюда и рождается необходимость проведения обследования, которое редко проводится бесплатно, а порой стоит 10-15% бюджета будущего проекта.

Но жадным 1С-никам и этого мало! После обследования они в лучшем случае дают оценку будущему проекту с дельтой в 30-50%. Почему? Вы же все же выяснили, изучили, что еще нужно?

Действительно, на этапе обследования специалисты в режиме интервьюирования выясняют, что происходит у Заказчика, как ведется работа сейчас, какие есть пожелания к будущей системе, что нравится, что нет. 
 
     
  Но итог обследования – это собранная в отчет информация. Нет никаких гарантий, что руководству нужно именно то, что хотят ключевые пользователи, и даже то, что само руководство на словах поведало специалисту. Очень часто бизнес-заказчики хотят видеть, как будет выглядеть работа их подразделений в новой системе. Как будут отражены текущие операции, часть из которых, возможно, еще делается вручную. И нередко видение бизнес-заказчиков сильно отличается от реализации подобных функций в типовом варианте системы. И никакое обследование не сможет дать однозначный ответ – совпадают ли видения у будущего Заказчика и Исполнителя, или после первого показа доработанной системы ее придется на 50% переделывать, т.к. «Тут у вас не так, и вообще я не это хотел».  И этот риск обязательно будет включен в оценку проекта, опять же сильно ее увеличивая. Однако верхнюю планку после обследования обычно удается определить, хотя цифры очень часто пугают Заказчиков, вплоть до отказа от продолжения работы, несмотря на то, что это теоретический максимум – его часто воспринимают как итоговую оценку.   
     
 
Как быть? Необходимо сделать так, чтобы видение будущей системы Заказчиком и Исполнителем совпали до старта основных работ по проекту. Заказчик должен увидеть будущую систему, понять, как в ней будут отражаться его процессы, а проектная команда должна заранее выяснить, какие процессы «лягут» на типовой функционал, а под какие систему надо дорабатывать (или наоборот – какие процессы Заказчик готов адаптировать под типовой функционал).
 
     
  Одним из вариантов достижения данных целей является этап моделирования – попроцессного сопоставления всех бизнес-процессов Заказчика с их отражением в предполагаемой к внедрению системе и демонстрацией сквозных примеров. На выходе обычно формируется документ под названием «Карта функционального покрытия», содержащий в табличном виде реестр процессов и все выявленные несоответствия действительности и реализации в системе, а также краткое описание будущих доработок, подробное описание которых будет представлять из себя, по сути, Техническое задание.   
 

Я всегда настаиваю на проведении моделирования, т.к. за адекватные деньги обе стороны получат в итоге одинаковое видение будущего проекта.


В целом, этот этап в первую очередь нужен для: 

- минимизации рисков сторон

- получения максимально адекватной оценки и формирования единого видения результата будущего проекта у всех его участников.
 
 
 

По итогам проведения моделирования Подрядчик и Заказчик:

- окончательно понимают, какие будут сложности в работе с данными конкретными людьми с другой стороны

- получают финальную оценку, которая с очень большой долей вероятности будет меньше чем та, которую дали по результатам обследования.
 
 
 

И хотя стоимость данного этапа порой может доходить до 30% бюджета всего проекта, выгода от его проведения в первую очередь для Заказчика, как показала практика, весьма существенна и в финансовом, и в функциональном плане.  

В последнее время при прочих равных я не продаю этап обследования как отдельный – сразу предлагаю моделирование с включенным в него обследованием. Выходные формы такого этапа (карта функционального покрытия) намного информативнее как для Заказчика, так и для любого подрядчика.
 
     
  Есть вопросы – обращайтесь!   
 

Дмитрий Шатохин,

аккаунт-менеджер ООО "Кодерлайн"

 

Задать вопрос автору статьи
Тема вопроса*
Ваше имя*
E-mail или телефон*
Ваш вопрос*
 

0
Владимир Коледов
Добрый день Дмитрий.
Прочитал вашу статью "Для чего нужно моделирование?". Неплохо.
Однако, позволю себе сделать небольшие комментарии.
1. В любом случае этап экспертизы текущего состояния IT системы Заказчика должен быть проведен. Спору нет. Результаты обследования и предлагаемая модель должны быть документально согласованы с Заказчиком и зафиксированы в ТЗ (которое готовит ИСПОЛНИТЕЛЬ). Такова практика.
2. С целью минимизации рисков целесообразнее придерживаться типовых конфигураций и предлагать Заказчику НАРАБОТАННЫЕ практикой IT системы (в разрезе ВИДОВ бизнеса, конечно). Т.е. всякий "Самопал" в управлении бизнес-процессами нужно стараться "отводить". Т.е. целевая функция лежит через тренинг. Нужно предлагать обучение сотрудников для правильного (по стандартам) управления бизнесом. Эти стандарты должны быть заранее разработаны Исполнителем.
Под корпоративными стандартами понимаются: Положения, Политика, Регламенты, Методики расчетов.

С уважением,
Коледов Владимир Вячеславович (48 лет, г. Санкт-Петербург)
e-mail: koledov@yandex.ru
конт.тел. +7 (999) 215-6930
Имя Цитировать 0
Добавить комментарий
Текст сообщения*
Защита от автоматических сообщений
 
Теги
#1С: CRM #1С: ERP #1С: ERP Управление строительной организацией #1С: ERP. Управление буровой компанией #1С: WMS Управление складом #1С: Аренда и управление недвижимостью #1С: БУХ #1С: Договорчики #1С: Документооборот #1С: ЗУП #1С: Интеграция #1С: КА #1С: Колледж #1С: Конвертация данных #1С: Платформа #1С: Розница #1С: Сценарное тестирование #1С: ТОИР #1С: УАТ #1С: УКФ #1С: Университет #1С: УНФ #1С: УПП #1С: Управление строительной организацией #1С: УТ #1С: УХ #ADO #APACHE #API #com-объекты #Excel #GoogleDrive #HTTP #ITIL #Koderline: Управление медиа-холдингом #Koderline: Управление проектами строительства скважин #LINUX #MS SQL Server #WEB #WEB-сервисы 1С #Word #XML #Администрирование 1С #Безопасность сервера #Бесшовная интеграция #БИТ.Финанc #Битрикс24 #Блокировки в 1С #БСП #БУ #Бурение скважин #Бюджетирование #Внедрение #Внедрение ERP #Закрытие месяца #Запросы 1С #Интеграция 1С #Как сделать в 1С #Конвертация данных #Корпоративное сопровождение #Лизинг #Лицензии 1С #Моделирование #МСФО #Налоги #Обмен между базами #Обновления #Оптимизация #Отпуск #Отчетность #Отчеты в 1С #Оценка задач #Перенос данных #Планирование #Полезные обработки #Правила обмена #Проводки 1С #Программирование в 1С #Программные права #Продажи #Производство #Расширение конфигурации #РСБУ #СКД #Сравнение конфигураций #Тестирование 1С #Техническое задание #Торговое оборудование #Транспортная логистика #Управление проектами #Финансовый учет #Ценообразование #Экзамен 1С #Яндекс.Касса Email или телефон
Услуги программиста 1С
Получите специалиста  
для решения всех задач
в области 1С
Программы 1С
Цены и подробное описание программ 1С:Предприятие 8.
Яндекс.Метрика