Техническое задание и Экспертиза ТЗ

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

           Недавно прочитал статью Пример технического задания и подумал, что тоже обладаю полезным опытом в этой области, особенно мне, понравилась идея использовать документ «Экспертиза техничного задания».

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

 

• не полностью соответствует существующему документообороту в организации

• не отвечает всем требования законодательства или корпоративных стандартов 

• может создать логические противоречия в документах и прочее

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

Все эти моменты может проконтролировать документ «Экспертиза техничного задания».

Документ «Экспертиза техничного задания» должен проконтролировать следующие пункты:
• Правильность постановки задачи (отсутствие двусмысленных моментов)
• Оптимальность: предложенного технического решения разработчиком
• Отсутствие дублирования функционала
• Применимость полученного результат для решения поставленной задачи
Выкладываю реальные примеры документов ТЗ и Экспертиза ТЗ.

 

Пример ТЗ

 

Отчет «ТЗ Отчет Товары на складах в суммовом выражении»


Задача

В базе УПП необходимо создать отчет, который будет брать основу с отчета Товары на складах, но при этом необходимо добавить поле Цены, которая будет браться либо

1)      Административная цена

2)      Закупочная (планирование)

3)      Цена в последний закрытый месяц

Данные цены будут выбираться на конец периода.

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

В отчете номенклатура будет представленная в единицах остатков номенклатуры.

 

Требуемый функционал

                Необходимо реализовать следующие возможности:

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

Группировки: Склад, номенклатура.

Замечание: Группировка по периодам не предполагается.

Планируемый результат

Отчет формируется в среднем от 2 до 4 раз в месяц, время, затрачиваемое на ручное формирование отчета приблизительно равно 1 рабочий день, таким образом на формирование отчета затрачивается от 16 до 32 ч.часов в месяц.

Трудозатраты на формирование одного автоматизированного отчета 3-5 минут, таким образом на формирование отчета будет затрачиваться от 0,1 до 0,3 ч.часов в месяц.

Ожидаемый эффект – экономия трудозатрат в размере от 15,7 до 31,9 ч.часов в месяц.

СОГЛАСОВАНО:

Заказчик:

Исполнитель:

Заместитель директора по экономике и финансам
ЗАО «Наши фирма»

____________________________/Петрова Н.Н./

Руководитель СИО ЗАО » Наши фирма»

_____________________/Сидоров В.А./


 

Решение

Отчет должен базироваться на системе компоновки данных (СКД), с использованием «Шаблона типового отчета», иметь возможность хранить несколько различных вариантов настроек (стандартный функционал УПП).

Вывести на форму список приоритет Типов цен номенклатуры (не более трех элементов).

Пример выбора цен:

 

Пользователь указывает период отчета, это период за который будут выбираться данные в колонках Начальный остаток количество, Приход количество, Расход количество, Конечный остаток количество. Цены для этой номенклатуры выбираются как срез последних с приоритетом по типам цен:

 

1)      Тип цены номенклатуры «Административная цена»  («самая приоритетная»)

2)      Тип цены номенклатуры «Закупочная (планирование)»

3)      Тип цены номенклатуры «Плановая»

Предположим по номенклатуре «Молодняк на откорме (свиньи)» указан период отчета 01.06.2012 – 30.06.2012.

 

При следующей возможной установке цен:

«Закупочная (планирование)»

30.06.2012

«Административная цена»

29.06.2012

«Закупочная (планирование)»

25.06.2012

«Административная цена»

02.06.2012

Будет выбрана цена «Административная цена» 29.06.2012.

При следующей возможной установке цен:

«Плановая»

28.06.2012

«Административная цена»

26.05.2012

«Закупочная (планирование)»

23.05.2012

«Плановая»

22.05.2012

«Административная цена»

01.05.2012

Будет выбрана цена «Административная цена» 26.05.2012.

При следующей возможной установке цен:

«Плановая»

28.06.2012

«Закупочная (планирование)»

23.06.2012

«Плановая»

22.06.2012

Будет выбрана цена «Закупочная (планирование)» 23.06.2012.

При следующей возможной установке цен:

«Плановая»

28.06.2012

«Закупочная (планирование)»

23.06.2012

«Административная цена»

02.03.2012

Будет выбрана цена «Административная цена» 02.03.2012.

При следующей возможной установке цен:

«Плановая»

28.06.2012

«Плановая»

22.06.2012

Будет выбрана цена «Плановая» 28.06.2012

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

 

Пример отчета приведен в Таблице 1.


 

 

Пример отчета

Склад

Количество (в базовых единицах)

 

 

 

Номенклатура, Базовая единица измерения

Начальный остаток

(кол/сумма)

Приход

(кол/сумма)

Расход

(кол/сумма)

Конечный остаток

(кол/сумма)

Цена

тип цен

 
 

Участок фасовки

 

 

105 239 636,29

13833050

104 778 867,69

13466900

460 768,59

210 479 272,57

 

 

 

 

 

Spektan-BSM d 40 Ливерная Славянская СТ, м

 

 

36 850,00

7370000

36 850,00

7370000

 

 

200

Закупочная

 
 

Spektan-BSM d 40, желтый  Паштет Петушок ТП, м

 

 

2 155,00

323250

980

147000

1 175,00

176250

150

Закупочная

 
 

Spektan-BSM d 50, золото, Ливерная Обыкновенная СТ, м

 

 

34 110,00

6139800

33 055,00

5949900

1 055,00

189900

180

Плановая

 
 

Таблица 1.


 

 

Таблица 3. Соответствия колонок отчета и источников данных

Колонки

Источники данных и комментарий

Начальный остаток, Приход, Расход, Конечный остаток

Выбираются данные по регистру накопления ТоварыНаСкладах

Цена

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

1)      Тип цены номенклатуры «Административная цена»

2)      Тип цены номенклатуры «Закупочная (планирование)»

3)      Тип цены номенклатуры «Плановая»

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

Начальный остаток, Приход, Расход, Конечный остаток (Сумма)

Эти данные в отчете уже имеются, вычисляется как «количество» *  «Цена».

Написать справку к отчету.

Интеграция

Отчет сохранить в базу УПП 2011: Внешние отчеты – Экономические –Товары на складах в суммовом выражении.

                Изменения созданы для конфигурации: Управление производственным предприятием, редакция 1.3 и Корпоративный менеджмент, редакция 6.2 (Версия 6.2.6.0). Используется в базе УПП.

 

Пример Экспертизы ТЗ

 

Экспертиза технического задания «Товары на складах в суммовом выражении»

 

Оценка постановки задачи

  1. Из формулировки следует, что цель отчета – получить хоть какие-нибудь суммовые оценки складских остатков («Лишь бы не нулевые»).
  2. При этом не конкретизируется, в каких случаях правильно использовать какой из указанных типов цен. («Какой будет»).
  3. Не понятен экономический смысл подобной оценки.

Справка:

Все указанные три цены несут разную смысловую нагрузку:

1. «Административная» — используется для принудительной установки значения себестоимости (обычно для — мяса на кости, или результатов разделки мяса на кости). Постулируется, что для целей бюджетирования данное МПЗ стоит именно столько независимо ни от чего (ни от фактической себестоимости, ни от закупочной цены).

2. «Закупочная (плановая)» равна средне-месячной цене закупки последнего месяца (считается ежемесячно). Имеет смысл для покупных материалов. Устанавливается на 01 число месяца.

3. «Плановая» (считается по закрытому месяцу). Для полуфабрикатов и продукции = себестоимости выпуска (упр. учет). Для материалов = Закупочной (плановой) из п.2. Устанавливается на последнее число месяца.

Оценка предлагаемого решения

Если принять постановку задачи, то предлагаемое решение:

  • • Технически грамотное
    • Легко реализуемое
    • Не дублирует существующий функционал.

Прогнозируемые риски

 

  1. Исходя из формулировки задачи, в случае, если для какой либо позиции номенклатуры была когда либо установлена «Административная цена» (даже 01.01.1980). То в дальнейшем будет использоваться только она (другие факторы на стоимость влияния иметь не будут).
  2. Исходя из формулировки задачи, если когда либо, один раз, некий полуфабрикат (обычно выпускаемый нами), будет по производственной необходимости куплен у поставщика (или оформлен возврат «Обратной поставкой») — отныне и навеки в отчет будет попадать его закупочная цена.
  3. Предложенная формулировка задачи приведет к тому, что согласно данным отчета, остатки на конец одного периода и остатки на начало следующего никогда не будут совпадать (из за разницы используемых цен в периоде).  Причем объяснить, откуда взялась эта разница (учитывая предыдущие два примера, будет очень сложно).

ВЫВОД:

Отчет сделать в требуемом виде можно, но его полезность – под большим вопросом.

Заказчик осознает и принимает описанные риски:

 

 

Начальник ПЭО

ЗАО «Наша фирма»

 

____________________/Д.С. Иванова/

 

«____» ____________ 2012 г.

 

Зам директора по экономике и финансам

ЗАО «Наша фирма»

 

____________________/Н.Н. Петрова /

 

«____» ____________ 2012 г.

Исполнитель

 

 

Руководитель СИО

ЗАО «Наша фирма»

 

____________________/В.А. Сидоров /

 

«____» ____________ 2012 г.

 

Системный аналитик

ЗАО «Наша фирма»

 

____________________/Д.В. Воронин/

 

«____» ____________ 2012 г.

 

3 Comments

  1. sapervodichka

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

    Reply
  2. PavelZnaikin

    А можите мне на почту прислать пример ТЗ. на Доработку 1С программы.

    Pavel.Znaikin@yandex.ru

    Reply
  3. Светлый ум

    Беру на заметку +1

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *