Бизнес анализ техническое задание

Техническое задание представляет собой документ, устанавливающий основное назначение и показатели качества ЭС, технико-экономические и специальные требования, предъявляемые к разрабатываемому изделию, стадиям разработки, составу и объему конструкторской документации.

Техническое задание составляется на основе исходного документа – заявки на разработку. В заявку на разработку входят следующие исходные данные: назначение изделия, предполагаемый изготовитель, ориентировочная потребность в изделии, стоимость разработки и сроки разработки, технико-экономическое обоснование, основные требования к конструкции и условия эксплуатации. В процессе согласования текста ТЗ эти данные подвергаются количественному анализу специалистами различных заинтересованных служб и могут существенно изменяться.

Техническое задание, как правило, делится на разделы, подразделы, пункты, подпункты и т.д. Многоуровневое структурирование текста ТЗ необходимо для выполнения в дальнейшем ссылок на отдельные его требования. Техническое задание, составляемое на выполнение ОКР, в общем случае имеет следующие разделы:

Создание дашборда: техническое задание на салфетке

· общие сведения о разработке;

· требования по видам обеспечения;

· требования к этапам и стоимости выполнения ОКР;

· порядок выполнения и приемки этапов ОКР.

Общие сведения о разработке содержат необходимую начальную информацию об изделии и его разработке: наименование, обозначение и область применения изделия; основание для разработки; цели и задачи разработки и др.

Раздел «Технические требования» в общем случае включает в себя подразделы: состав изделия, показатели назначения, требования по надежности, конструктивные требования, условия эксплуатации, требования по безопасности, транспортирование и хранение, эстетические и эргонометрические требования к изделию и др.

В разделе «Технико-экономические требования» приводят требования, обеспечивающие разработку изделия в обоснованных пределах полной стоимости его жизненного цикла и с оптимальной трудоемкостью серийного производства и технического обслуживания в процессе эксплуатации.

В разделе «Требования по видам обеспечения» приводят требования по метрологическому и программному обеспечению для разрабатываемого изделия.

В заключительном разделе ТЗ приводят номер стандарта, регламентирующего порядок выполнения и приемки выполняемого ОКР (основной стандарт – ГОСТ Р 15.201-2000), а также необходимое количество опытных образцов для испытаний, место проведения испытаний и др.

В учебных проектах исходным документом (заявкой на разработку) для составления ТЗ служит задание по подготовке проекта. На его основе студенты с помощью руководителя проекта составляют ТЗ на разработку изделия. По согласованию с руководителем из текста ТЗ могут быть исключены разделы и подразделы, являющиеся второстепенными по отношению к задачам дипломного проектирования.

Целью разработки может быть не только создание нового изделия, но и модернизация или модифицирование изделия (см. приложение А). В этих случаях в распоряжении разработчика имеется вся документация на прототип, включая технические условия (ТУ), комплект чертежей и др. Поэтому нет необходимости в ТЗ подробно излагать все требования к разрабатываемому изделию, достаточно привести только изменения, которые должны быть достигнуты для разрабатываемого изделия по сравнению с прототипом.

Проектная документация. Какие документы готовят бизнес и системный аналитики?

Более подробная информация по разработке ТЗ содержится в методических указаниях по выполнению практических занятий, разработанных на кафедре.

Анализ ТЗ производится с целью определения основных направлений создания конструкции и состоит в оценке степени важности множества взаимосвязанных факторов, оказывающих влияние на принятие решений, таких как:

· назначение и область применения проектируемого изделия;

· функциональные параметры изделия;

· условия эксплуатации, определяющие меру воздействия внешней среды (пределы изменения температуры и атмосферного давления, влажность, уровни механических воздействий);

· требования к конструкции (масса, габариты, надежность, ремонтопригодность, тепловые режимы и др.);

· технико-экономические характеристики (стоимость, технологичность, степень стандартизации и унификации, сроки морального износа);

· организационно-производственные факторы (размер партии, серийноспособность и др.);

· наличие и уровень развития элементной базы.

При анализе каждому требованию ТЗ необходимо поставить в соответствие обоснованное техническое решение, обеспечивающее выполнение данного требования.

Принятие исходных технических решений производится на основе обзора литературных источников (учебников, учебных пособий, монографий, статей) по следующей схеме: возможные методы решения задачи → критический анализ каждого из методов → выбор лучшего метода по результатам сравнения количественных или качественных критериальных оценок.

Обзор должен охватить большую часть вопросов, имеющих непосредственное отношение к разработке изделия: состояние развития элементной базы; особенности применения в изделиях радиотехнических и конструкционных материалов; организация внутренней структуры конструкции (компоновочные схемы, способы электрических соединений и др.); способы защиты ЭС от внешних климатических и механических воздействий; методы обеспечения нормальных тепловых режимов и выбор системы охлаждения.

Принятые на основе анализа исходные решения должны определить основные направления разработки конструкции.

В дипломном проектировании обзор литературных источников является одной из задач преддипломной практики и в отдельных случаях включает список патентной литературы. Принятые в результате анализа ТЗ технические решения в процессе проектирования детализируются и уточняются.

Источник: poisk-ru.ru

Как самому написать техническое задание для ИТ службы

Основываясь на 23 летнем опыте работы в бизнесе ИТ компании, я четко могу сказать, что в 90% всех обращений клиентов за внедрением 1С, разработкой дополнительного функционала или автоматизаций 1С нет четко сформулированной цели и критериев результата, что приводит к недопониманию целей и процесса реализации, к объемам работ и выделяемого бюджета.

Один не спросил, другой не сказал. Попробуем разобраться подробнее, что с этим делать. Как сделать внедрение 1С максимально эффективным, а автоматизацию результативной.

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

С другой стороны, бытует мнение, что программист 1С должен знать все, обладать знаниями в любой области деятельности бизнеса и с полуслова понимать любого пользователя информационных систем, предвидеть всевозможные отклонения и риски.

Идеальный вариант разработчика 1С, когда он же руководитель в своей компании. Тогда процессы происходят в одной голове, и проблем при передаче информации не существует.

При других вариантах, даже если программист 1С вам озвучит, что да, он все понял, имейте ввиду, что понял настолько, насколько он понимает ваш процесс и вашу специфику.

Рассмотрим кейс одной компании «Не идет баланс»

Звонок бухгалтера программисту 1С: «Вадим, мне срочно нужно исправить баланс, он не идет на 5000 рублей!» Мысли программиста 1С: «Не идет актив с пассивом, сейчас открою форму отчета через конфигуратор и допишу в формуле пассива «-5000» и делов-то!» Выполняет задание. Проходит 10 минут. Программист сообщает бухгалтеру, что все выполнено — пусть проверяет.

Бухгалтер счастлива, какой с ней замечательный специалист работает, берет дешево, делает быстро, просто волшебник!

А теперь давайте разберем этот кейс с помощью следующих вопросов:

• Четко ли бухгалтер поставила задачу?
• Правильно ли понял ее специалист?
• Соответствует ли решение истинному запросу бухгалтера?
• Устраивает ли полученный результат работы специалиста бухгалтера?
• По каким критериям проводится приемка работ?

• При постановке задачи «не идет баланс» она озвучила ожидаемый результат, что в итоге она хочет решить, но не обозначила, в чем конкретно причина.
• Разработчик 1С понял задачу ровно так, как ее поставили: если не идут две колонки отчета, их нужно уравнять в формуле расчета этих колонок.
• Метод решения направлен не на исправление и поиск ошибки в учете, а на механику формирования отчета.
• Подобный результат может устроить неквалифицированного бухгалтера, а вот профессиональный обязательно спросит, а что было исправлено, где была допущена ошибка.
• Главное, какой критерий приемки работ ожидается бухгалтером, механика отчета или поиск причины выявленного отклонения и ее исправление.

Кейс от компании «У нас процессы согласования как у всех»

Запрос от директора производственного предприятия по внедрению внутреннего электронного документооборота в компании.

Целью озвучено «ускорение процесса согласования рассмотрения договоров от поставщиков». Сейчас на предприятии процесс происходит на протяжении 2-3 недель, потому что очень много ответственных в листе согласования.

Запрос: «Рассчитайте нам стоимость внедрения 1С:Документооборота, и побыстрее. Процессы у нас такие же, как во всех предприятиях. Ждем от вас предложение, выбираем по цене, конечно, же. Где дешевле, там нам выгоднее».

Вопрос от специалиста 1С для осуществления расчета трудозатрат по внедрению: «Можете ли предоставить зафиксированный процесс согласования, существующий сейчас в зависимости от вида документа?

Есть ли какие либо особенности, например, по договорам до 100 тысяч рублей или более 100 тысяч рублей?

Ответ со стороны заказчика: «Вы же профессионалы, вам виднее, вы сами все должны знать. Ждем предложения от вас.»

Результат таких запросов очень часто бывает следующим:

• Подготавливается коммерческое предложение по внедрению программы, среднестатистической, которое в дальнейшем не попадает в бюджет при реализации проекта в связи с тем, что особенности предприятия открываются в каждом процессе. Это приводит к негативу с обеих сторон и расторжению договора, бессмысленной трате денег и сил с обеих сторон.
• Подготавливается коммерческое предложение по внедрению программы, в которое закладываются существенные возможные риски (те, кто уже попадал в первый вариант развития событий). И снова провал: стороны не договорились, потому что цены слишком большие и непонятно, из чего взяты для расчета.

• Четко ли поставлена задача? — конечно, нет
• Правильно ли понял ее специалист 1С? — понял из своего опыта (заложил риски своих неудач).
• Соответствует ли решение истинному запросу директора? — я бы сформулировала цель следующим образом: «Сейчас компания теряет …. тыс. рублей из-за длительных сроков согласования внутри компании. Во сколько нам обойдется внедрение этого процесса, чтобы ускорить процесс до 2-4 часов».
• Устраивает ли полученный результат работы компании? — однозначно нет. Оба варианта принесли затраты как времени, так и денег, не принеся положительного результата.
• По каким критериям проводится приемка работ? — критерии не были озвучены.

Так что же делать?

В кейсах уже есть наводка на вектор направления для решения. Но немаловажно зафиксировать информацию и закрепить ее с двух сторон.

Одним из эффективных источников фиксации информации является технического задание.

Давайте рассмотрим структура технического задания со стороны заказчика:

1. В какой системе предполагается разработка/интеграция между какими системами.

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

Например: создание дублирующего справочника «Причины отказа клиентов» от заказа клиента, или дублирование «Сегмента номенклатуры».

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

2. Кто выступает инициатором со стороны заказчика (ФИО, должность, контакты, доступность данного лица в ближайшие 3 месяца)

Эти данные необходимы для уточнения и согласования деталей по задаче. Иногда ответственным назначают человека, до которого очень сложно достучаться из-за его высокой загруженности, или он отсутствует на предприятии продолжительное время (отпуск, больничный, командировки). А от этого будут зависеть сроки приемки и тестирования работ.

3. Критичность задачи по сроку реализации

Обычно клиент говорит, что разработка нужна была еще вчера, сроки горят. Здесь нужно реально подойти к вопросу сроков и принять решение решить вопрос в ручном режиме, или срок реализации разработки уложится в ваши ожидания.

4. Название и путь до базы данных

Для экономии времени на организационные моменты уходит до 8 часов, и это только для того, чтобы уточнить, из какой базы данных выгрузить копию или на какой базе потом проверять доработку.

• Подключение к серверу и разворачивание копии для разработки и тестирования потребует места на вашем сервере, к этому нужно быть готовым.
• Передача базы разработчику обычно происходит после оформления соглашения о конфиденциальности. Разворачивается она на отдельном диске с ограниченным доступом для сотрудников компании. В этом случае все работы производятся на серверах исполнителя.
• Вариант разработки на типовой конфигурации предусматривает отсутствие прямого доступа к вашей базе данных, но увеличивает объем работ по внесению данных для тестирования и корректности отработки кода.
• В нашей компании разработан еще один вариант. При заключении договора на выполнение работ мы настраиваем регламенты снятия копий на отдельные выделенные защищенные сервера для хранения. Доступ к этим копиям есть у системного администратора заказчика и у нас, как у ответственных за регламент снятия бэкапов. В этом случае нам не приходиться беспокоить заказчика и копии для разработок мы разворачиваем самостоятельно.

От ответа на этот пункт зависит, включается ли в объем работ время на загрузку и выгрузку копий для разработки, на организацию бэкапов этой базы в случае объемных работ.

7. Описание самой задачи

Очень важно сформулировать задачу правильно и четко. Некорректный вариант: создайте обработку по замене сырья в спецификациях.

Корректный вариант: разработать для технолога производства инструмент по замене сырья в спецификациях с указанием коэффициента списания сырья через создание новой спецификации в статусе «Действующая». Предусмотреть перевод в статус «Не действующая» спецификаций, по которым прошла замена сырья.

8. Ожидаемый результат

Результат всегда должен быть измерим. Поэтому при формулировке обязательно отвечаем на вопросы, кто будет пользоваться данным результатом, какую эффективность он получит, в чем это может быть выражено и как замерить эффективность.

9. Описание текущего бизнес-процесса

Если вы умеете описывать процессы в графическом виде, это замечательно. Если же нет, то придется описать в словесной форме. Возьмем вышеуказанную задачу для примера.

Технолог получает задачу от директора по производству заменить наименование импортного сырья на российский аналог с 01.04.2022 года.

Технолог, получив задание, в ручном режиме открывает спецификации, в которых присутствует импортное сырье, и меняет его на российский аналог. Технолог не успевает выполнить задание в срок, так как объем спецификаций очень большой.

В результате, при оформлении заказа в производство списывается импортное сырье, которого нет фактически на складе. А российский аналог копится на складе, искажая реальные остатки для своевременной закупки следующей партии.

10. Описание желаемого бизнес-процесса

Пример того, что хотим: Технолог, получив задание от начальника производства, формирует журнал спецификаций в базе 1С:ERP (1С:Управление производственным предприятием). Через отбор выбирает сырье, которое необходимо заменить, проставляет, на какое сырье требуется заменить. При этой манипуляции старые спецификации сохраняются по сроку действия, так как они уже запущены и участвуют в выпуске продукции. А новые спецификации с российским аналогом сырья начинают действовать с определенной даты и будут задействованы при оформлении нового заказа в производство. Технолог должен успевать в срок до 1 дня по исполнению задачи по замене сырья в спецификациях, при этом списание сырья при выпуске продукции должно произвестись по действующей спецификации на момент запуска заказа в производство.

11. Ограничения

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

Пример: Данный функционал доступен только для пользователя технолог. У бухгалтеров не должно быть права менять спецификацию самостоятельно.

12. Как будет происходить тестирование разработки и кто принимает в нем участие

Описываем последовательность действий пользователя при тестировании. Не забыть проверку описанных ограничений.

Сразу будет понятно, кто из персонала заказчика потребуется для тестирования, и необходимо будет предусмотреть возможность выделить им время для тестирования.

Пример: Технолог заходит под своим пользователем в 1С:ERP, открывает раздел АРМ Технолога, выбирает импортное сырье и осуществляет отбор спецификаций со статусом «действующая». Выбираем позицию для замены из российского сырья, проставляет коэффициент списания по сравнению с импортным сырьем и запускает обработку. Фиксируем время выполнения – тайминг.

Начальник производства заходит под своим пользователем в 1С:ERP, производит тестовый запуск нового заказа на производство, делаем тестовый выпуск продукции и проверяем, по каким спецификациям списалось сырье на выпуск.

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

Заходим в 1С:ERP под пользователем бухгалтер, пробуем изменить спецификацию. Если обнаруживаются отклонения, снова фиксируем в протокол.

13. При достижении каких критериев/ показателей работы считаются принятыми

Важно прописать измеримые и понятные показатели. Например:

• технолог на замену спецификаций должен потратить не более 4 часов;
• корректность данные проверяется сопоставлением с отчетом «Ведомость по остаткам на складах» по графе списание за день;
• оформление заказа клиента у менеджера должно занимать не более 5 секунд при звонке постоянного клиента с подбором истории продаж;
• списание сырья на основании выпуска из производства должно соответствовать количеству в действующей спецификации на дату запуска заказа.

14. Анализ эффективности доработки для компании (экономический эффект от внедрения)

Расчет экономического эффекта важен для понимания того, сколько средств вы сэкономили для компании, сопоставив их с объемом средств по разработке. Исходя из этих данных и формируется понимание эффективного сотрудничества с ИТ специалистами.

Например: перевод диспетчерской службы 7 подразделений Хлебзавода на 1С:ERP сэкономила компании более 776 400 рублей ежемесячно.

Расчет до внедрения: 7 заводов, в каждом на приеме заказов работало по 3 диспетчера в смене при минимальной зарплате 12 000, график сутки через двое. Получаем сумму: 7 производственных площадок * 3 смены * 3 диспетчера * 12 000 (зп) = 756 000 ежемесячно + 24% налоги с ФОТ = 937 440 рублей ежемесячно.

Расчет после внедрения: централизовали диспетчерскую службу, перевели ее в управляющую компанию. В центральную диспетчерскую перевели 5 сотрудников, график работы Пн.-Пт., дежурства Сб, Вс не полным составом. Максимально автоматизировали прием заказов от торговых сетей без участия диспетчеров, прием заказов по телефону не более 5 сек. на заказ, при звонке через АТС программа сама определяет клиента и сразу выводит на экран диспетчеру заказ клиента в открытом виде с подобранными товарами, которые они брали за последние 7 дней, цена уже стоит в заказе, диспетчеру осталось только количество внести со слов клиента. Средний чек по заказу вырос, так как программа автоматически подсказывает, что еще клиент может заказать к пасхе, например. Итог: 5 человек * 26 000 рублей + 24% налоги с ФОТ = 161 000 рублей ежемесячно.

Экономия в результате автоматизации 776 400 рублей! Стоимость проекта на 2020 год по этому этапу составила 2,5 млн. рублей включая оборудование по IP телефонии. Затраты по проекту окупили себя за 3,5 месяца!

Когда подводится экономический эффект от внедрения, приходит понимание, что это того стоило.

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

Наша компания Soft+ 5 апреля провела закрытую экспериментальную мастерскую «Напиши техническое заданием сам», направленную на подготовку пользователей 1С самостоятельно составлять технические задания как своим ИТ службам, так и ИТ компаниям.

Эксперимент признали удачным, и мы готовы выпустить формат данной мастерской в общедоступный режим. Узнать подробнее вы можете, перейдя по ссылке.

Источник: soft-plus.ru

Составление ТЗ

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

В процессе бизнес-анализа и написания технического задания участвуют:

• Бизнес-аналитик;
• Аккаунт-менеджер;
• Технический специалист отдела внедрения или разработки;
• Менеджер отдела продаж;
• Основной куратор со стороны Заказчика;
• Уполномоченные представители со стороны Заказчика.

Результатом проделанной работы по бизнес-анализу и формализации задач на внедрение Битрикс24 выступает техническое задание на этап, общим объёмом не более 80 часов с детальным описанием настроек. Согласованный список работ используется в качестве критериев приёмки в период приемо-сдаточных испытаний.

В ходе выполнения бизнес-анализа может быть разработана следующая документация:

1. Бизнес-карта процессов компании. Документ, отражающий внутренние взаимосвязи по направлениям работ компании и распределение зон ответственности и действий.

2. Текстовое описание задач. Документ, содержаний описание внедрения через согласованные с заказчиком методы реализации и критерии приемки.

3. Итоговая смета этапа. Составляется при заказе услуги Этапная настройка. Представляет собой таблицу с перечнем работ и оценкой реализации в часах, днях и рублях по итогам проведенного анализа на этап.

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

Стоимость услуги:

Составление технического задания — 80 000 руб.
Срок выполнения — не более 15 рабочих дней.

Оформить заказ на услугу

Составление ТЗ с ПУСК это:

1. Бесплатная предварительная консультация — обсуждаем ход настроек и плановое число этапов работы в зависимости от целей внедрения
2. Работа с бизнес-аналитиками с техническим опытом внедрения системы Битрикс24 не менее 3-х лет
3. Регулярные двусторонние встречи для координации движений по проекту
4. Прозрачная работа по задачам и удобная коммуникация
5. Используемый подход исключает крупные финансовые затраты: не нужно единоразово оплачивать весь проект – процесс делится на этапы, каждый из которых сразу будет приносить пользу и практический результат

Источник: i-pusk.ru