Как написать техническое задание для программиста 1с образец заполнения

Время на прочтение
4 мин

Количество просмотров 28K

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

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

Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.

Итак, приступим.

Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:

• Формы ввода информации
• Контрольные процедуры
• Модель данных
• Алгоритмы автоматического заполнения данных
• Формы вывода информации

Давайте отдельно рассмотрим каждую категорию.

Формы ввода информации

Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).

Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.

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

Контрольные процедуры

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

В эту категорию попадают:

• Матрицы ролевого доступа
• Правила предоставления доступа к полям форм и данных
• Проверки корректности заполнения данных в формах ввода
• Процедуры сверки данных

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

Модель данных

Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.

Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:

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

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

Алгоритмы автоматического заполнения данных

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

Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.

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

Формы вывода информации

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

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

Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.

***

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

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

P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?

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

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

С чего начать? Два способа.

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

Я расскажу о двух способах как составить подробное ТЗ.

Первый способ — это движение от вопросов. Задать их нужно тем, кто работает в программе. Например: Какой отчет нужен для более полного представления данных?

Сотрудник рисует колонки, объясняет, что они отражают. И все это заносится в задание на разработку.

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

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

Второй способ — это движение от задачи. Например, задача: «настроить обмен между сайтом и основной базой». Представьте, что этот обмен уже работает, какие данные и куда попадают? Напишите в задание свое видение!

Что должно содержать ТЗ

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

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

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

Исходя из своей практики, могу порекомендовать вот эти пункты:

• назначение и цели создания (развития) системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по созданию системы;
• порядок контроля и приемки системы;

Я их взял из ГОСТ 34.602-89 поищите в интернете. Он родом из СССР, но актуальность не потерял до сих пор!

Пример технического задания

1  Назначение системы

Разработка конфигурации «Управление Гостевым домом».

Целью создания системы является организация учета по управлению гостевым домом:

1. Заказов на бронирование номеров, а также их заселение и уборку.
2. Прибылей и убытков в любой момент времени.
3. Имущества в номерах.
4. Организация учета проживающих граждан

Задачи создания системы.

Создаваемая конфигурация «Управление Гостевым домом» предназначена для решения следующих задач:

­  организация приема заявок и бронирования;

­  учет заселения постояльцев и хранение их данных;

­  учет закупок расходных материалов;

­  учет прибыли, доходов и расходов Заказчика;

­  учет имущества в номерах;

­  создать отчеты и печатные формы для карточек номеров и заселения;

­  создать отчеты по финансовой деятельности.

Объектами автоматизации являются:

✅ рабочее место менеджера на ресепшен

✅  рабочее место руководителя

✅ рабочее место обслуживающего персонала

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

В этом разделе мы расскажем Вам, как составить техническое задание программисту 1С и что такое Составление ТЗ. Сразу заметим, что всё нижеизложенное является только советом, основанном на нашем опыте работы, и ни в коем случае не требованием, предъявляемым к составлению ТЗ. Основным результатом работы и для заказчика и для исполнителя, естественно, является сама программа, но кроме этого заказчику важно, чтобы работа была выполнена быстро, качественно и недорого, а для исполнителя очень важно верно оценить объем и не потерять клиента. Не секрет, что любая база данных — это не просто программа, а сложный механизм, который дорабатывается и улучшается на протяжении всего срока использования. Поэтому программист всегда старается сохранить перспективные отношения с клиентом и, учитывая Ваши интересы, старается подсказать как правильно, быстро и недорого реализовать проект.

Чем отличается Проект от Технического задания? Проект — это намерение разработать некий механизм автоматизации учёта или желание получать быстрые и точные отчёты от уже имеющийся системы. Начинается он с назначения руководителя проекта. Им может быть либо сотрудник фирмы заказчика, либо фирмы исполнителя; во втором случае, естественно, все услуги по ведению проекта войдут в его стоимость. Далее, в случае с «1С:Предприятием», выбирают и изучают типовую конфигурацию по вопросам её возможностей и необходимости в доработках. Только после соответствующего анализа руководитель проекта составляет доскональное и точное задание программистам на внесение изменений в конфигурацию. Это задание и называется Техническим заданием (ТЗ), и именно составление ТЗ рассматривается в данном разделе.

Есть ли смысл изменять конфигурацию? Этот вопрос требует серьёзного рассмотрения. Все конфигурации, работающие с бухгалтерской компонентой, в некоторой степени — правовые системы, т.е. кроме функций расчёта и хранения информации от них требуется соответствующее государственным законам ведение учета. Для этих программ фирмой «1С» ежемесячно выпускаются обновления 1С, как форм отчётности, так и самих конфигураций. Но что получится, если Вы измените программу, а после установите обновление? Все Ваши изменения пропадут. Можно каждый раз восстанавливать их, но зачастую это практически то же, что делать работу заново. В данной ситуации самый лучший способ — выполнять все доработки во внешних модулях. Рассмотрим конфигурацию, доработка которой, по мнению пользователей, необходима — «Торговля и Склад». Необходимость доработки — это не значит, что программный продукт некачественный, наоборот, эта конфигурация, пользуется огромной популярностью. В своём базовом варианте она способна работать в разных торговых сферах деятельности. Но у каждого бизнеса есть свои нюансы, и совмещать их в одной программе не имеет смысла.

Теперь перейдем к теме. У Вас возникла идея изменить программу или автоматизировать учёт. В своём воплощении любая идея проходит 4 стадии: Проектирование -> Реализация -> Проверка -> Анализ. В перспективных долгоживущих проектах после Анализа снова следует Проектирование, замыкая тем самым «круг»; такой цикл будет существовать на протяжении всего срока эксплуатации программы. Как показывает практика, для воплощения идеи необходимо 3-4 цикла, потом, через какое-то время, возникнет новая идея, но её реализация потребует меньших усилий. Что бы воплотить Ваш проект в жизнь при минимальных финансовых затратах, необходимо найти опытного исполнителя. Но, каким бы опытным не был программист, в первых двух циклах стадии: Проектирования, Проверки и Анализа желательно выполнять своими силами, при соответствующих консультациях исполнителя. Очень важно не жалеть времени на изучение материала -типовой конфигурации. Писать программу с «нуля» не имеет смысла, так как приобретая «1С:Предприятие» Вы в любом случае в комплекте получите конфигурацию. Как показывает практика, именно на стадии Проектирования возникает до 80% ошибок, особенно при разработке нестандартных решений, из-за неправильно сформулированных требований. Опытному программисту не стоит большого труда воплотить практически любое задание в жизнь, но его работа — это Ваши деньги и время; следовательно, чем точнее и продуманнее задание, чем ответственнее вы подходите к составлению ТЗ, тем быстрее и дешевле реализация.

Рассмотрим основные принципы составления ТЗ:

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

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

3. При составлении ТЗ в начале разработки помните о том, что это задание, а не весь проект и постарайтесь объяснить программисту, что от него требуется в результате. Снабдите его образцами форм, сделанными в Ms Excel, Ms Word или нарисованными от руки, но в точности такими, какие Вы хотите получить. Постарайтесь не использовать подобных объяснений: «интерфейс должен быть предельно понятным», «документы желательно распечатывать по какой-то форме», «по результатам нужно, чтобы строился какой-то отчёт» или «документы как-то должны попадать в 1С:Бухгалтерию». Если Вы попросите оценить подобное задание, то цена может быть 10-1000 у.е., точнее сказать трудно. Лучше сформулируйте так: «интерфейс документа похож на документ Реализация ТМЦ», «необходимо две печатные формы, образцы прилагаются», «по результатам необходим следующий отчёт, его форма в Excel-файле». Разрабатывать обмен данными между базами лучше после накопления некоторого опыта работы с ними и проведения основных доработок, связанных с изменением структуры программы.
Вывод: постарайтесь в первом задании как можно подробнее объяснить программисту, что от него требуется. В дальнейшем задания могут иметь более свободную форму, всё зависит от взаимопонимания с исполнителем.

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

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

«1С:Предприятие» пользуется огромной популярностью, и при серьёзном подходе к вопросу проектирования, результат оправдает Ваши ожидания. С помощью программирования возможно реализовать любые схемы учёта, но заказчику необходимо вполне определённо представлять результат, который он хочет получить.

1) Общие сведения, назначение и цели доработки
Необходимо сформулировать цели доработки и для чего в конечном итоге она предназначается. Данный пункт должен быть уточнен глобальными целями.
2) Характеристика объектов автоматизации.
Нужно указать, что именно мы будем разрабатывать в терминах платформы «1С». Какие объекты метаднных будут добавлены к конфигурации, какие изменены и в какой части. Данный пункт Постановщик составляет совместно с Исполнителем по результатам работы с Заказчиком
3) Требования к системе.
Заказчик излагает свои требования в виде списка. Определяются критерии оценки эффективности выполнения требований.
4) Состав и содержание работ по созданию системы.
Исполнителем составляется план работ, который утверждается Заказчиком.
5) Порядок контроля и приемки системы.
Заказчик назначает ответственных специалистов по тестированию доработок, определяются порядок и сроки тестирования, согласовываются с Исполнителем.
6) Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие.
Заказчик предоставляет требования по начальным корректировкам ИБ, осуществляемым через пакетный ввод данных.
7) Требования к документированию.
Постановщик и Исполнитель утверждают содержание документации по доработке.

Надеемся, что наши советы помогут в составлении ТЗ и решении Ваших задач.

Небольшое вступление

Данная статья – это сухая выжимка нашего опыта, который мы получили в результате выполнения более чем 20000 различных заданий. Мы действительно считаем, что такой подход к написанию ТЗ – наиболее простой и результативный.

Что требуется от заказчика

Обычно заказчики сталкиваются с тем, что достаточно сложно объяснить коротко и понятно то, что им нужно на «программистском языке». Многие из них пытаются объяснить свои потребности путем рисования экранных форм в Paint-е или оформления сложных блок-схем.

Правило: не нужно делать лишнюю работу!

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

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

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

Вот примерный перечень сведений, которые должен указать в ТЗ заказчик:

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

При этом:

• если задача касается изменения какого либо существующего бизнес-процесса и затрагивает сразу несколько его ветвей, то лучше приложить схему всего процесса;
• если нужно доработать отчет (например, добавить новые колонки),  то рекомендуется подготовить итоговый макет. Для этого можно сохранить нужный отчет из 1С в эксель, там добавить недостающие графы и полученный результат выслать программисту;
• если нужно обеспечить загрузку из внешнего файла (например накладной из Excel), то необходимо приложить к ТЗ пример такого файла;
• если нужно устранить всплывающие ошибки, то сделать сканы этих ошибок или на худой конец, подключить специалиста по Teamviewer или Anydesk, что бы он самостоятельно визуально их зафиксировал. Чем больше визуальной информации  — тем лучше!

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

Чем должен дополнить ТЗ специалист:

• описать какие объекты конфигурации(регистры, справочники, документы и т.п.) он будет добавлять/изменять и как заказчик будет с ними в результате взаимодействовать.
• итоговый дизайн интерфейса (где и какие поля и кнопки будут располагаться)
• дать оценку сроков и стоимости реализации поставленной задачи!

Или как же избежать траты времени и бессмысленного слива денег на неудачные внедрения 1С?

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

Один не спросил, другой не сказал. Попробуем разобраться подробнее что с этим делать.

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

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

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

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

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

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

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

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

· Правильно ли понял ее специалист?

· Соответствует ли решение истиному запросу бухгалтера?

· Устраивает ли полученный результат работы специалиста бухгалтера?

· По каким критериям проводится приемка работ?

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

· При постановке задачи «не идет баланс» она озвучила ожидаемый результат, что в итоге она хочет решить, но не обозначила что хочет знать в чем конкретно причина отклонения;

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

· Метод решения направлен не на исправление и поиск ошибки в учете, а на механику формирования отчета.

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

· Главное, какой критерии приемки работ ожидается бухгалтером, механика отчета или поиск причины выявленного отклонения и ее исправление.

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

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

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

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

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

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

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

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

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

Как же избежать траты времени и бессмысленного слива денег на неудачные проекты? Возвращаемся к нашим вопросам:

• Четко ли поставлена задача? – конечно нет

• Правильно ли понял ее специалист 1С? – понял из своего опыта (заложил риски своих неудач)

• Соответствует ли решение истиyному запросу директора? – я бы сформулировала цель следующим образом: «Сейчас компания теряет… . тыс. рублей из-за длительных сроков согласования внутри компании, во сколько нам обойдется внедрение этого процесса, чтобы ускорить процесс до 2-4 часов»

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

• По каким критериям проводится приемка работ? – критерии не были озвучены

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

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

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

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

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

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

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

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

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

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

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

· Передача базы разработчику обычно происходит после оформления соглашения о конфиденциальности, разворачивается она на отдельном диске с ограниченным доступом для сотрудников компании. В этом случае все работы производятся на серверах исполнителя;

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

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

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

Очень важно сформулировать задачу правильно и четко.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· технолог на замену спецификаций должен потратить не более 4 часов;

· корректность данные проверяется сопоставлением с отчетом «Ведомость по остаткам на складах» по графе списание за день;

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

· списание сырья на основании выпуска из производства должно соответствовать количеству в действующей спецификации на дату запуска заказа;

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

Например: перевод диспетчерской службы 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 апреля 2022 года провела закрытую экспериментальную мастерскую «Напиши техническое заданием сам», направленную на подготовку пользователей 1С самостоятельно составлять технические задания как своим ИТ службам, так и ИТ компаниям.

В Мастерской приняли участие 18 представителей, среди которых наши клиенты, методисты и разработчики компании Soft+. Посмотрели на материал со всех заинтересованных сторон, определили как лучше отработать формат.

Эксперимент признали удачным, и мы готовы выпустить формат данной мастерской в общедоступный режим. Узнать подробнее вы можете на нашем сайте Витрина вебинаров Soft+ (soft-plus. ru)

Мария Эсмонтова, Управляющий партнер ИТ компании Soft+; Сертифицированный практик бизнес-ТРИЗ 2 уровня; +79272713948,