Одна из самых больших проблем в любом, особенно, большом деле – это начать. Всегда на старте возникает масса вопросов. С чего начать? Как начать таким образом, чтобы получить тот результат, который нужен? И здесь на помощь приходит философия.
Почему так важно правильно начинать? Только одно начало ведет только к одному концу.
Это важно понимать. Например, если мы вместо бани построили сарай, скорей всего, мы с самого начала строили именно сарай. В будущем мы, конечно, можем переделать сарай в баню или баню в сарай. Но это уже другая история. А здесь смысл в том, что от того, как мы начнем, будет зависеть то, как мы закончим.
Как бы это ни казалось тривиально, но многие люди просто не задумываются о подобных вещах.
Согласно диалектике результат, например, внедренная IT-система (важно, не просто реализованная, но внедренная!), это – развернутое начало.
Как видите, и философия, и жизнь подсказывают одно: начало и результат всегда связаны. И если мы говорим о результате, мы также говорим о начале. При этом начало нам очень и очень важно.
Как составить техническое задание (ТЗ)?
Все начинается с идеи
В начале было слово.
В начале создания любого программного обеспечения нужно слово. Это бриф. Иначе говоря – идея. Когда мы хотим создать любое программное обеспечение, сначала нужно сформировать идею.
Эта идея может быть описанием процесса, какой-то задачей, описанной в сжатом виде. Такое описание должно быть коротки, занимать не более 1-2 абзацев ( 1 т символов) и четко выражать суть того, что мы хотим получить в результате.
Для примера, идеей может быть: «Разработать IT-систему для контроля взаиморасчетов» или «Разработать IT-систему для автоматизации продаж». Также это может быть описание процесса, например, в таком виде:
«При необходимости в товаре которого нет в наличии продавец создает документ заявка на закупку и направляет его на согласование закупщику. Закупщик проверяет необходимость в закупке данного товара и если закупщик разрешает закупить товар согласно заявке на закупку, то продавец информируется о разрешении закупить товар, и закупщик создает заказ поставщику. Иначе заявка аннулируется с комментарием содержащем причину отказа в закупке. Продавец информируется об отказе в закупке».
Таким образом, в самом начале нам нужно сжато и четко сформулировать идею. Именно от нее мы будем отталкиваться в дальнейшем и на нее ориентироваться, чтобы получить нужный результат.
Как формулировать идею
Идея — это не так просто, как может показаться. Здесь очень важно четко сформулировать, что именно вы хотите получить. Я предлагаю для этого как можно подробнее узнать у ведущего специалиста или ответственного лица, что именно ему необходимо. После чего нужно сформулировать идею не только сжато, но обязательно в такой форме, которая будет понятна этому человеку. После этого сформулированная идея обязательно согласовывается.
Очень важно в процессе формулировки идеи не уйти в сторону и не углубляться в ненужные на этом этапе подробности. Часто уже на этом этапе люди пытаются расписывать подробные брифы. В итоге, основное внимание уделяется подробностям и нюансам. На самом деле, это не правильно.
ТОП-9 советов как написать техническое задание? (ТЗ или техзадание за 9 шагов)
Главное — это идея, т.е. четкое понимание целей, которые вы хотите достичь в результате реализации проекта. Она может быть описана текстом, может быть сразу в виде графического процесса. Самое главное — четкое и однозначное понимание результата. Подробности оставьте для последующих этапов.
А что если мы хотели совсем не то, что в итоге получилось?
Этот вопрос-возражение нередко задают заказчики. Обычно он звучит так:
“Мы хотели CRM-систему, а написали, что нужна ERP” или “Нам нужна была CMS для сайта, а мы написали CRM”.
Ошибки в терминологии – распространенная проблема. А в сфере IT терминология сложна и очень важна. Потому лично я посвящаю правильной терминологии множество публикаций.
Чтобы избежать проблем и недопонимания, лучше всего изучить терминологию заранее. Не поленитесь лишний раз убедиться, что вы в идее правильно называете конечный продукт.
Ну, а если в процессе согласований не возникло каких-то сложностей, и вы получили результат, который помогает решать поставленные задачи, скорей всего, вы просто ошибочно использовали термины. И когда говорили “CRM” на самом деле имели в виду ERP или наоборот.
Еще раз: уделяйте максимум внимания терминам. Уточняйте их значение в статьях на моем сайте, при общении со специалистами, в справочниках. Это поможет точнее сформулировать цель, избежать разногласий и составить корректное техническое задание.
Графическое описание процесса
После того, как заказчик сформулировал идею, нам нужно провести более подробное интервью, разобраться в важных нюансах, после чего создается графическое описание процесса.
О том как описать процесс вы можете почитатьздесь
Почему так важен процесс? Подробно об этом вы можете почитать в моей статье «Бизнес-моделирование», где описаны основные подходы. Также вас может заинтересовать статья «Про процессный подход», где вы также можете подробно прочитать о том, почему важны процессы и как с ними работать.
В двух словах, нам необходимо разложить поставленную задачу на какой-то определенный процесс или процессы. Лично я рекомендую для этого использовать формат BPMN. На данный момент — это стандарт, который наиболее проработан с точки зрения автоматизации бизнеса.
Подробнее о BPMN вы также можете почитать в моих публикациях.
- Сравнение нотаций IDEF3, IDEF0, BPMN и DFD
- Как описать бизнес-процесс в формате нотации BPMN и других.
Независимо от выбора инструмента, диаграмма должна отвечать на вопрос «Как мы хотим получить тот или иной результат».
Например, если мы говорим о продажах, по ней должно быть понятно, что является началом, допустим, заявка клиента, и концом процесса. Это может быть отгрузка, заключение контракта и пр.
Еще один пример – Запись клиента на услуги. Здесь также нужно описать последовательность действий, начиная с момента обращения клиента до момента непосредственно записи на услугу.
Текстовое описание
Теперь, когда мы описали процесс графически, обсудили его, получили согласие, приходит время, как говорится, «добавлять на кости мясо». Т.е. на полученный каркас в виде общей диаграммы мы начинаем «наращивать» детали, как именно будет выполняться работа на каждом из этапов.
В графической модели мы не можем подробно детализировать все нюансы. Более того, в этом нет необходимости, излишние подробности только усложняют восприятие. Для этого существует текстовое описание.
Например, в графической модели мы указали «Создать заявку». В самой диаграмме этого достаточно. Но в текстовом описании мы указываем, что необходимо для создания заявки. Это может быть перечень полей (Клиент, Сумма заявки, Комментарий и пр.).
Аналогично при создании Сделки на основе заявки, в тексте описываются поля «Сумма сделки», «Перечень товаров», «Клиент», «Этап» и т.д.
Требования к текстовому описанию:
- Текстовое описание должно полностью описывать тот процесс, который есть в графическом описании.
- Дополнительно в текстовом описании должно быть все, что необходимо для разработки решения и передачи его в работу программистам.
Если идея нужна для руководства, в основном, BPMN-диаграмма – для руководства и сотрудников высшего звена, т.е. тех, кто будет принимать решения и в общем контролировать ситуацию, то текстовое описание нужно для программистов. С помощью диаграммы и текстового описания они уже смогут реализовать решение.
План
У нас уже есть понимание, что из необходимых и полезных инструментов уже имеется в наличии. Есть знание, к чему мы должны прийти. План отражает последовательность действий, которая нужна для достижения поставленной цели.
Например, у нас в процессе должен создаваться звонок и подключаться автоматически запись разговора. Значит, нам нужно:
- Подключить IP-телефонию, если она еще не используется.
- Интегрировать телефонию с системой.
- Настроить запись звонков и выбрать для этих записей хранилище.
Еще один распространенный пример – на данный момент сайт заполняется вручную. Необходимо настроить автоматическую выгрузку на сайт. В плане мы так и ставим задачу: «Автоматическая выгрузка данных на сайт. Разработка скриптов переноса данных из учетной системы на сайт информации».
Таким образом, в план мы собираем задачи по автоматизации, а также указываем исполнителя и сроки. При этом нет необходимости указывать фамилии исполнителей. В плане важно указать просто: «программист», «консультант».
Я лично так понимаю:
- Программист – это тот человек, который будет писать программный код.
- Консультант – человек, который будет контролировать работу программиста.
- Старший консультант – это человек, который будет осуществлять общее руководство проектом.
Иногда, если в этом есть необходимость, я указываю, что определенную задачу будет выполнять не просто программист, а, например, 1С-программист.
Требования к плану:
- В плане должны быть отражены все задачи, которые нужно выполнить, чтобы получить из того, что есть, то, что должно быть
- В плане должны указываться четкие сроки выполнения задач, и кто исполнитель
Подробнее эти этапы работ вы также можете изучить из моей статьи «Использование GAP-анализа для выявления и согласования задач по проекту».
Пример плана
Здесь также все просто. Берем задачу, пересчитываем ее на рабочие часы, умножаем на стоимость часа и получаем расчет стоимости задачи. Саму методику вы можете изучить подробно в статье «Как рассчитать стоимость внедрения программного продукта»
Кинзябулатов Рамиль
Бизнес консультант
Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org
Вам также может понравиться
Что такое компьютерная информационная система
Подробное описание компьютерных информационных систем (иначе – IT систем). Значение термина простыми словами. Чем поможет понимание особенностей IT систем для взаимодействия с разработчиками. Как правильно выбрать программную систему.
Техническое задание на автоматизацию. Каким оно должно быть, состав и технологии создания
Одна из самых больших проблем в любом, особенно, большом деле – это начать. Всегда на старте возникает масса вопросов. С чего начать? Как начать таким образом, чтобы получить тот результат, который нужен? И здесь на помощь приходит философия.
Использование GAP-анализа для выявления и согласования задач по проекту
Что такое GAP-анализ и какие задачи он помогает решать. Основные этапы работы. Диагностика и ее разновидности. Чем интересен метод GAP-анализа для анализа выбранных решений. Преимущества графики.
А что у них? Обзор американской бухгалтерии QBD
QBD (QuickBooks Desktop) – это информационная система для ведения бухгалтерского учета, созданная в США. В этой статье я хочу показать особенности работы и возможности этого программного продукта.
Как выбрать IT систему
Правильный выбор IT системы — это работа, которая требует времени, сил и грамотного подхода. Как действовать при выборе программного обеспечения? На какие параметры обращать внимание при сравнении различных инфомационных систем? Подробно, с примерами и полезными советами читайте в статье.
Внедрение программного продукта. Особенности работы бизнес-консультанта
Что такое внедрение программного продукта с точки зрения заказчика и бизнес-консультанта. Основные этапы работы по внедрению программной системы, как работать с клиентами и обосновывать свой выбор правильно. Ошибки при внедрении.
Обзор ERP на базе Drupal 9
В данной статье мы предлагаем вам полный обзор ERP, созданной на основе Drupal 9 для зооклиники «Зоостатус». Хотел бы сразу поблагодарить руководителя этой компании Михаила Тарасова за предоставленную возможность рассказать про эту систему и заместителя генерального директора Асию Калимуллину за всесторонюю помощь и координацию работ со стороны заказчика.
Источник: trinion.org
Оказание услуг по проведению обследования бизнес-процессов компании и формированию технического задания на разработку и внедрение корпоративной информационной системы управления предприятием на базе программных продуктов «1С:ERP Управление холдингом» и «1С:ERP Энергетика 2».
Описание секции Закупки корпоративных заказчиков Номер извещения 32312296829 Номер закупки 69 (69-1704-23) Наименование закупки Оказание услуг по проведению обследования бизнес-процессов компании и формированию технического задания на разработку и внедрение корпоративной информационной системы управления предприятием на базе программных продуктов «1С:ERP Управление холдингом» и «1С:ERP Энергетика 2». Начальная цена 4 787 664.04.2023 08:29 МСК
Ускоренная регистрация за 1 час!
Успеть подать заявку на участие в этой торговой процедуре возможно только с ускоренной аккредитацией. Рассмотрение документов при самостоятельной регистрации составляет пять рабочих дней по регламенту площадки.
Источник: etpgpb.ru
Тех задание по бизнес процессам
Техзадание помогает найти общий язык. Документ полезен для всех сторон – при написании заказчик может структурировать свои бизнес-процессы, пожелания, улучшения, а для разработчиков техзадание служит инструкцией. Самое главное, что это – исходный документ всего проекта, эталон, которому надо стараться соответствовать и с помощью которого можно решать практически все спорные вопросы.
Фото: Unsplash