Этот образец технического задания составлен, по большей части, для руководства компании — людей, которым надо управлять компанией и не нужно глубоко погружаться в тонкости процессов разработки.
Преследовалась цель: ознакомить и согласовать с руководством основные принципы реализации проекта. И чтобы предложить руководителю компании доступным и понятным для него языком путь реализации проекта.
На мой взгляд,
данный образец может быть полезен тем, кто составляет описания и задания на разработку и внедрение, работая на стороне Заказчика.
Входящие требования для разработки технического задания:
— Учет номенклатуры на адресном складе в разрезе занимаемого в ячейке (объема) не ведется.
— Предполагается работа с оборудованием (терминалами сбора данных) под только в режиме «Off-Line» или без оборудования в неавтоматизированном режиме.
— Склад адресного хранения должен быть универсальным и доступным для применения в учете в других регионах.
Образец текста примера технического задания на организацию и разработку склада адресного хранения содержащегося в файле:
Техническое задание на организацию склада адресного хранения в конфигурации «Региональное Предприятие»
Входящие требования для разработки технического задания:
— Учет номенклатуры на адресном складе в разрезе занимаемого в ячейке (объема) не ведется.
— Предполагается работа с оборудованием (терминалами сбора данных) под только в режиме «Off-Line» или без оборудования в неавтоматизированном режиме.
— Склад адресного хранения должен быть универсальным и доступным для применения в учете в других регионах.
Примечание:
Техническое задание разрабатывается без учета возможности работы адресного склада с оборудованием (ТСД), способным работать с базой данных в режиме «On-Line».
Ячейка адресного хранения:
Реализация на физическом складе:
– конкретная, пронумерованная ниша в стеллаже (этаж стеллажа), в которую размещается учитываемый товар в конкретном, пронумерованном стеллаже.
Реализация в программе:
— ячейка адресного хранения соответствует конкретному элементу справочника «Ячейки» в программе учета.
Адрес ячейки:
Реализация на физическом складе:
— в виде конкретного, визуально удобно читаемого печатного номера формата «номер склада»-«номер блока»-«номер линии»-«номер стеллажа»-«номер этажа (яруса) в стеллаже». Как дополнительная возможность, после «номера яруса» может следовать «номер подъячейки». Т.е. этаж (ярус) в стеллаже может разбиваться на дополнительные ниши хранения – подъячейки. В номере так же располагается штрихкод ячейки в формате CODE93. Для удобства визуального восприятия таблички адреса ячейки, основные составляющие адреса (номер линии, стеллажа, яруса) печатаются большим жирным шрифтом.
Реализация в программе:
— физический адрес ячейки типа «9-1-11-001-2-3» содержится в поле «Код» элемента справочника «Ячейки». Так же этот адрес по умолчанию дублируется в поле «Наименование». Поле «Наименование» доступно для изменения, в него можно внести любое наименование ячейки, для удобства восприятия, например «Приемка». Физический адрес ячейки, содержащийся в поле «Код» типа «9-1-11-001-2-3» остается неизменным.
Физический адрес формируется на основе заполненных данных в реквизитах элемента справочника «Ячейки»:
— «Склад» — ссылка на элемент справочника «Склады», заполняется один раз, изменению не подлежит. Устанавливает принадлежность ячейки конкретному складу в программе учета
— «Номер Склада» — значение, реквизита «НомерСкладаАдресногоХранения» элемента справочника «Склады». Может принимать значения с номерами от 1 до 9. Устанавливается один раз при генерации ячейки, изменению не подлежит.
— «Блок» — родительская группа «линии» элемента справочника «Ячейки», номер блока принимает значения от 0 до 9
— «Линия» — родительская группа элемента справочника «Ячейки», значения от 01 до 99
— «Стеллаж» — целое число, длина 3, значения от 001 до 999
— «Ярус» — целое число, длина 1, значения от 0 до 9….
При составлении данного образа технического задания не преследовалась цель создать его по ГОСТу и в соответствии с авторитетными нормативными требованиями.
Этот образец технического задания составлен, по большей части, для руководства компании — людей, которым надо управлять компанией и не нужно глубоко погружаться в тонкости процессов разработки.
Преследовалась цель: ознакомить и согласовать с руководством основные принципы реализации проекта. И чтобы предложить руководителю компании доступным и понятным для него языком путь реализации проекта.
На мой взгляд,
данный образец может быть полезен тем, кто составляет описания и задания на разработку и внедрение, работая на стороне Заказчика.
Входящие требования для разработки технического задания:
— Учет номенклатуры на адресном складе в разрезе занимаемого в ячейке (объема) не ведется.
— Предполагается работа с оборудованием (терминалами сбора данных) под только в режиме «Off-Line» или без оборудования в неавтоматизированном режиме.
— Склад адресного хранения должен быть универсальным и доступным для применения в учете в других регионах.
Перейти к публикации
Какое-то очень поверхностное описание работы. 🙂 Не хватает оформления.
Невнятно весьма. Не зря все-таки ГОСТ на тех задание придуман.
Хорошо бы оформить в соответствии с ЕСПД… А так, толку от этого «конкретного, визуально удобно читаемого» 🙂 документа ноль.
Кстати, в соответствии с этим техзаданием я, как заказчик, отправил бы вас на склад сначала собирать и расставлять стеллажи (согласно подпункту «Реализация на физическом складе» пункта «Ячейка адресного хранения» технического задания), а потом клеить на них номера (согласно подпункту «Реализация на физическом складе» пункта «Адрес ячейки»). И в итоге не заплатил бы за готовую программу, т.к. она не соответствует техническому заданию: при проведении документа «Перемещение между ячейками» товар на физическом складе никуда не телепортируется. А должен, согласно
Для оптимальной раскладки уже распределенного по ячейкам товара может возникнуть необходимость переложить товар из ячейки в ячейку.
Например, товар подбирается из ячеек редко, но находится в самых удобных для доступа ячейках, занимая место и мешая разместить в эти ячейки более ходовой товар.
Для обеспечения этой процедуры предлагается использовать описанный выше документ «Перемещение между ячейками», но с другим видом операции «Перемещение».
В общем, ТЗ — важный документ и подходить к нему надо аккуратно и вдумчиво. На крупных проектах составление и согласование ТЗ может составлять до 40% общего времени разработки.
При составлении данного образа технического задания не преследовалась цель создать его по ГОСТу и в соответствии с авторитетными нормативными требованиями.
Этот образец технического задания составлен, по большей части, для руководства компании — людей, которым надо управлять компанией и не нужно глубоко погружаться в тонкости процессов разработки.
Преследовалась цель: ознакомить и согласовать с руководством основные принципы реализации проекта.
Если это ТЗ — для руководства, то не хватает картинок, схем…
Они наглядней гораздо текста!
как своевременно =)
как раз внедряем! спасибо
Отличная публикация, завтра же дам прочитать нашему складисту, пусть учится.
(6) Stamper, точно )
А цель написать грамотно описание (не смотрел само ТЗ) преследовалась? 🙂
«под только в режиме» — ниасилил 🙁
внедряю сейчас собственную систему адресного склада на базе 1С 7.7 Рарус Фармацевт, поэтому было интересно почитать,
некоторые ваши пункты (например один отчет) включил в план разработки у себя,
есть несколько замечаний/комментариев к вашему ТЗ
1. 2 регистра для Адресного Хранения (АХ) — Остатков и Резервов. Наличие Резервов АХ необоснованно «утяжеляет» систему, все возникающие задачи мы планируем решить с помощью регистра остатков АХ
2. размерность Количества — целая, а если количество дробное ??? хоть и понимаю, что это редкое явление, все же оставил 3 знака Количества
3. Создание движений по АХ обычными товарными документами — с одной стороны удобно (как точка входа/выхода Товара в/из системы АХ, с другой — в нашей товарной системе возможно проведение документа задним числом, в системе же АХ заднее число было исключено программно и эта политика была одобрена административно, таким образом создание движений по АХ обычными товарными документами с их использованием заднего числа неприменимо у нас.
4. основная единица товара, например, в медицине — Серия, хорошо если под Характеристикой товара понималась именно Серия,
в этой связи сомнительно, что нужно для учета АХ оставлять 3 измерения Ячейка/Товар/Характеристика, мы у себя оставили только Серия/Ячейка, где Серия — подчинена Товару.
из пожеланий — прошу отписать, сталкивались ли с проблемой и о выбранных способах решения, проблема:
в момент инвентаризации, кладовщики определяет серию товара «на глазок» (пересорт по сериям) и при занесении инвентаризации приходится относить фактическое количество по сериям, отдавая себе отчет, что фактически заносимые данные по сериям могут не совпадать с реальным
(11) Свой, если кладовщики не ведут количественный учет по сериям, то каким образом вы хотите получать реальный остаток на складе в разрезе серий номенклатуры?
По-моему соображению, ячейка, подвергающаяся инвентаризации, должна блокироваться и в ней должны считать товар вплоть до серии (характеристики).
(12) поддерживаю.
Учет или есть или его нет. Промежуточные варианты мне кажутся здесь неприемлемыми. Могут существовать промежуточные варианты — например, адресный склад без количественного учета по ячейкам — но весь смысл в том, что есть установленные РЕГЛАМЕНТЫ и они должны ВЫПОЛНЯТЬСЯ. Если регламент не допускает оценки «на глазок» — такой оценки не должно быть.. Мне кажется, что там где есть оценка «на г лазок» — или реально н икто не заинтересован в учете как таковом или нет МОЛОв, РЕАЛЬНО отвечающих за количества/серии/порядок… и все идет на уровне атата-погрозили пальчиком…
Я гляжу, в комментариях более продвинутые ТЗ чем в исходной публикации. Мне тоже кажется что ТЗ на организацию складского учета без маршрутизации(и ее оптимизации) погрузки — разгрузки, это задание вхолостую… В ТЗ должна оговариваться оптимизация размещения номенклатуры и маршрутизация погрузочно — разгузочных работ — чтобы людипогрузчикик не метались туда сюда по складу просто так.
— это вам действительно кажется. у меня склад примерно на 8 тысяч ячеек, высотный, узкопроходный. Прекрасно обходимся без маршрутизации — ясен пень это не просто так получилось.
.
В общем — да, в ТЗ д.б. много чего.
реально — ТЗ ПИШЕТСЯ НА КОНКРЕТНЫЙ ЧАСТНЫЙ СЛУЧАЙ.
(15) CheBurator, за что минус?
Вроде ты поддерживаешь автора, я правильно понял?
составление ТЗ — сложная задача
А мне понравилось. Использовать как «щаблон» вполне можно.
Правда вот «ознакомить и согласовать с руководством основные принципы реализации проекта … доступным и понятным для него языком путь реализации проекта.»
Не получилось — доступным не получилось, начальство ничего не полняло ))))
(18) alaudit, не ощибается тот, кто не работает 🙂
публикация нормальная ………….
ТЗ разрабатывается индивидуально для каждого случая. Рекомендую к прочтению Эдвард Фразелли «Мировые стандарты складской логистики» чётко прописано проведение анализа.
Как составить подробное техническое задание на IT- обеспечение ? Своими словами объяснить могу а как дело доходит до общения с IT- отделом возникает полное непонимание. Может кто подскажет или ссылку кинет где посмотреть.