Это продолжение темы статьи. Отличия в том что я переработал структуру, добавил глоссарий и поменял название на более соответствующее материалу. Данная статья будет дополняться и изменения будут отражаться либо здесь либо на сайте. На сайте же сможете скачать саму модель в высоком разрешении для печати и изучения.
Правила Хабра запрещают ссылки на свой контент поэтому эта статья написана в корпоративном хабе, который не всегда может быть у меня (автора). Именно по этому изменения модели будут размещаться прежде всего на сайте.
Проблематика
Уже более 17 лет я, тем или иным образом, занимаюсь внедрением и разработкой программного обеспечения. Значительная часть моих решений предназначена для моих клиентов в России и за рубежом. Все они связаны с вопросами автоматизации и оптимизации работы компаний. Одной из важных проблем при таком сотрудничестве всегда оказывается вопрос, с чего начать и как понять, из чего состоит предприятие.
Я перепробовал разные способы, и почти всегда при этом работал по процессной модели. Мне ставили определенные задачи, я описывал один, два, три процесса, и, в принципе, всех это устраивало. Но меня не покидала мысль о том, что есть всё-таки какая-то универсальная модель предприятия, которую можно использовать из раза в раз. И если для меня она со временем стала интуитивно понятной, то для людей, которые только начинают свою деятельность в этой сфере или не сталкиваются постоянно с автоматизацией, а потому не имеют такого опыта, как я, конечно, возникает множество вопросов, Большинство из них связаны с тем, с чего начинать работу, как и что в каждом из случаев внедрять, и вообще, как строить свое сотрудничество с клиентами и зарабатывать в этой сфере.
В связи с этим я решил описать, то есть создать некую почти универсальную модель. Я к ней шёл уже, наверное, лет десять.Конечно, я не занимался ее разработкой все это время. Но уже десять лет назад у меня были первые, скажем так, черновики такой модели.
Почему функции, а не процессы?
Ответ на этот вопрос очень просто. Процесс, в принципе, не подходит для описания модели предприятия. Конечно, существуют сквозные процессы и я о них уже писал ранее. В одной из прошлых статей я подробно описал, почему сквозные процессы не подходят, и почему я них не верю. Также я уже не единожды писал уже о том, что такое функциональная модель, как в этом случае моделировать, и чем эта модель отличается от процессной. В общем, по итогу изучения разных вариантов я пришел к выводу, что для той модели, о которой я говорил выше, процессы не подходят, здесь нужны функции.
Почему именно функции? Потому что каждая из функций – это некий "черный ящик", и она может быть автоматизированна отдельно от других. То есть в общей модели у нас есть функция. Далее мы выбираем нужную и сразу видим, что мы хотим получить, что мы имеем на входе, какое ПО для этого нужно использовать и чем руководствоваться. То есть то, что как раз написано в стандарте IDEF0(перевод описания этого стандарта есть в моем блоге).
Как читать модель
Модель нужно читать слева направо, сверху вниз. То есть сначала мы читаем название функции, потом, что в нее входит, что вводится, что выводится. И так шаг за шагом каждую модель. Затем, если мы хотим понять, что нам необходимо, чтобы эта функция работала, мы смотрим на стрелки, которые идут снизу вверх. Это механизмы, которые необходимы: программное обеспечение, сотрудники и так далее.
Что делать, если за несколько функций отвечает один человек?
Важно понимать, что в случае работы с моделью, мы говорим не о конкретных людях, а, так сказать, о механизмах.
Механизмы — виртуальное понятие. То есть у вас может быть один человек, который выполняет несколько разных функций. Например, в каких-то случаях может отсутствовать руководитель или, например, оператор ЭВМ. В вашем случае продажник может сам заниматься созданием заявки в учетной системе, создавать и печатать документы, и он же несет ответственность за то, что происходит с этими заявками дальше.
Но но при этом роль оператора ЭВМ в модели должна быть. Потому что за каждую функцию почти всегда должен нести ответственность отдельный человек или отдельная организационная единица.
Далее, сверху вниз вы увидите стрелки контроля или, как их еще называют, стрелки управления. Часто их путают с управлением с точки зрения, наличия какой-то штатной единицы руководящего персонала или еще чего-то подобного в иерархии предприятия. Это неправильно. В данном случае это именно то, чем руководствуются внутри функции люди и механизмы, чтобы получить на выходе результат из этой функции.
А есть ли такая модель для производственной организации?
Сейчас я создал модель для торговой компании. Но уже получил вопросы о том, можно ли сделать что-то подобное для производства. На самом деле, под производственную организацию модель меняется очень просто. Я ее обязательно сделаю и выложу отдельно. Но, в принципе, она отличается от торговой только тем, что мы не закупаем товар, а производим продукцию, которую, соответственно, потом продаем. То есть у нас вместо закупок товара будет производство продукции. И внутри функции уже нужно будет выполнить, в том числе, закупки материала, после чего собрать изделия или ещё что-то в этом роде.
Можно ли сделать программное обеспечение на основе этой модели?
Да, можно. Я уже создавал ERP-систему для одной из организаций, которая построена по этому принципу. То есть я сначала описывал модель в IDEF0, а потом уже – - процессы в BPMN и, соответственно, автоматизировал, т.е. разработал программное обеспечение.
Вы также можете поступить подобным образом. При этом автоматизация может состоять из одной или нескольких программных систем. К примеру, для функции «привлечь покупателя» или «продать товар» вы будете использовать какую-то маркетинговую или CRM систему, а для «отгрузить товар» вы можете использовать свою учётную систему или WMS-систему, в зависимости от того, что у вас есть, или что вы планируете использовать. С другой стороны, функции «продать товар» и "отгрузить товар" могут быть автоматизированы в одной учетной системе. Все зависит от ваших целей.
Как я давал названия
Названия функций в этой модели — в принципе устоявшиеся названия из проектов, на которых я работал. То есть исходя из требований к модели, я давал каждому элементу уникальное название в рамках этой модели. Потому, если речь не идет об одном и том же, допустим, о товаре, вы не найдете в модели названий стрелок или любых других элементов, которые были бы разными по смыслу, но одинаковыми по названию.
Модель
Диаграмма A-0
Диаграмма A0
Самая главная функция называется — распорядиться товаром.
Почему распорядиться товаром? Почему не получить прибыль? Я здесь намеренно изменил название основной функции, по той причине, что организация как таковая не получает прибыль. Прибыль получают в конечном итоге собственники, акционеры — те, кто получает дивиденды от этой организации. Все остальные работают, как наемные сотрудники, и в связи с этим они не получают прибыль.
Соответственно, торговое предприятие работает именно как организация, которая распоряжается товаром. То есть на основе спроса она закупает товар, который потом распределяет, распоряжается им по своему усмотрению согласно уставу, нормативной документации и так далее.
Привлечь покупателя
Первая функция — «привлечь покупателя». Это функция, которая отвечает за то, чтобы мы привлекли покупателя на основе спроса и подготовили его к покупке товара, т.е. получили согласие на покупку, согласовали заявку и т.д.. В рамках этой функции покупатель готовится непосредственно к продаже нами ему товара в дальнейшем.
Продать товар
«Продать товар» — это функция, которая отвечает за то, чтобы мы могли на входе иметь заявку клиента. Это может быть заявка в любой форме. Может в форме «заказ клиента», причем, сам клиент оформляет этот документ как «заказ поставщику». Впрочем, со стороны клиента заявка может называться как угодно, главное, чтобы в ней был непосредственно заказ. Также она может быть получена различными методами. Это может быть заявка на сайте или электронное письмо — всё что угодно. То есть это самое общее название. В вашем случае вы можете подставить всё, что вам надо и получить на выходе товар, который необходимо продать, вернее, отгрузить.
Закупить товар
После того, как мы продали товар, то есть мы обязались поставить какой-то товар по определенной цене человеку или организации, мы должны проверить, есть ли он на складе и при необходимости закупить. Соответственно, эта функция получает на входе потребность в товаре, который мы продали, то есть обязательства, которые у нас есть. Эту заявку мы должны отправить своему поставщику.
Сохранить товар
После того, как поставщик нам товар этот отгрузил, мы должны его принять от поставщика. То есть «сохранить товар» — это функция, которая принимает на входе товар и выдаёт его получателю.
Здесь необходимо отметить следующий момент. Почему называется получатель? Не покупатель, не клиент, не ещё что-то. Потому что получатель может быть, как покупатель, так и, к примеру, внутренний сотрудник, который получает этот товар. Но он всё равно будет называться получатель. Это может быть получатель, который своими силами делает доставку, и это не покупатель получает, а ваш, допустим, экспедитор.
Доставить товар
Функция «доставить товары» отвечает за то, чтобы товар был доставлен покупателю. Вот здесь необходимо объяснить, почему «переместить» и «выдать товар» выделены отдельно. Мы можем переместить товар, а выдавать может кто-то другой. К примеру, мы можем привезти товар на какой-то склад хранения или передать, например, курьерской службе или еще кому-то, кто этот товар непосредственно передаст. По этой схеме работают, так называемые, пик поинты. То есть мы отвозим посылку в шкафы, а покупатель уже её получает. Соответственно, мы должны выделить эту выдачу товара покупателю в отдельную функцию.
Глоссарий
Нормативная документация— это вся документация, которая собрана и на основе которой работает организация: будь то устав, будь то должностные инструкции, будь то ценовая политика, стратегии и тому подобные вещи. В дальнейшем я расшифрую это понятие.
Спрос — это спрос на товары и продукцию. Здесь всё понятно.
Персонал — это сотрудники, которые выполняют те или иные виды работ.
Товар — это тот товар, который получает непосредственно покупатель.
Привлечь покупателя— это функция, которая отвечает за анализ спроса, генерацию плана продаж и запросов покупателей на покупку.
Понятно, что план продаж— это документ, согласно которому отдел продаж работает и продает товар. Здесь важно понимать, что план продаж необходим, как управляющий документ для отдела продаж.
Запрос покупателя на покупку— это всё, что угодно. Это может быть заявка покупателя. Это может быть заказ поставщику, если он исходит от покупателя. Если он исходит непосредственно из отдела продаж, то это может быть заявка, заказ покупателя. Выполняет эту работу отдел маркетинга.
Фирменный стиль, здесь всё понятно, — это определенные фирменные цвета, шрифты, требования к упаковке и тому подобные вещи, которыми руководствуется маркетолог при оформлении предложения.
Ценовая политика — это документ, в котором указано по какой цене продавать товар, скидочные позиции и тому подобные вещи. Это может быть как документ, так и словесно переданное руководителю сообщение. Он и сам может это понимать, но всё равно руководствуется определенной ценовой политикой.
Требования к оформлению заказа покупателя — это просто требования в виде инструкции о том, как нужно оформлять заказ, который поступил от покупателя.
Ценовая политика — здесь всё понятно.
Правила закупки товара — это правила, по которым закупается товар: по какой цене, откуда, от каких поставщиков и тому подобные вещи.
Требования к хранению товара — это требование, которое необходимо для хранения определенного товара. К примеру, если мы храним пищевые продукты, то требуется наличие холодильника, отрицательных температур и соблюдение ещё каких-то определенных требований.
Правила доставки товара — это правила, по которым доставляется товар: срок доставки, каким образом оповещается покупатель о доставке и тому подобные вещи.
Отдел продаж — это подразделение, которое занимается непосредственно оформлением продаж.
Отдел закупок — это то подразделение, которое занимается непосредственно закупкой товара.
Склад — это помещение, где хранится товар.
Отдел доставки — это подразделение, которое отвечает за доставку товара покупателю.
Потребность в товаре — это могут быть записи в базе данных, либо заявка на закупку того или иного товара, согласно которой отдел закупок занимается непосредственно закупками.
Поручение на выдачу товара — это может быть накладная, это может быть ТОРГ-12, это может быть всё, что угодно. То есть это тот документ, согласно которому склад выдает товар получателю.
Обязательство по доставке товара — может быть в виде документа ТОРГ-12, может быть в виде счёт-фактуры, а может быть просто в виде накладной в какой-то свободной форме, где зафиксировано то, что в указанное время проданный товар будет отгружен покупателю, то есть доставлен покупателю.
Продать товар — это функция, которая отвечает за продажу товаров.
Закупить товар — этот функция, которая отвечает за закупку товара, согласно потребности в товаре.
Сохранить товар — это функция, которая отвечает за то, что закупленный товар будет сохранен для дальнейшей его доставки.
Доставить товар — это функция, которая отвечает за доставку товара покупателю.
Функция проанализировать спрос — отвечает за анализ спроса на рынке. Каким образом это происходит? Раз в год или раз в квартал, допустим, собирается руководство организации и отдел маркетинга и смотрит, что нужно на рынке, а что не нужно, оформляет это в виде данных анализа спроса. Это может быть план продаж, это могут быть категорийные матрицы. Это может быть все, что угодно, где указано, какие товары и по какой цене мы хотим продавать в ближайшем будущем.
Они делятся на два типа. Первое — это план продаж на определенный период. Второе — данные анализа спроса, которые непосредственно нужны для того, чтобы мы могли прямо сейчас уже рекламировать то, что нам необходимо. Они содержат не только количественные параметры, но и ценовые параметры, а также то, как нужно представлять товар, где нужно его представлять и подобные вещи.
Функция создать предложение для рынка — отвечает за то, что после того, как данные анализа спроса к нам попали, нам необходимо оформить это в виде какого-то предложения, которое в дальнейшем увидит наш покупатель. Это может быть как простой буклет или объявление в соцсетях, так и просто описание продуктов.
Функция прорекламировать предложение на рынке. Эта функция отвечает за рекламу. Что это значит? Это значит, что мы можем разместить полученное объявление в соцсетях, на телевидении, радио — где угодно, для того чтобы о нём узнали. После того, как о нас узнали, продуцируется запрос покупателя на покупку. О том, что такое запрос покупателя на покупку, мы уже говорили.
Функция обработать заявку покупателя — отвечает за то, чтобы поступившую заявку в отделе продаж обработали в том виде, в котором её возможно анализировать для дальнейших функций.
Функция создать коммерческое предложение — отвечает за то, чтобы из поступившей заявки создать коммерческое предложение. Что такое коммерческое предложение? Коммерческое предложение — это заявка с проставленной ценой и условиями от поставщика.
Функция согласовать коммерческое предложение с покупателем. Данная функция отвечает за процесс согласования с покупателем коммерческого предложения. Это может быть переписка, это могут быть встречи и ещё какие-то моменты.
В результате, в этой функции заданы обязательства перед покупателем по доставке товара. Обязательства перед покупателем могут выглядеть как заключённый, то есть подписанный, договор, либо заказ клиента с подписями, либо коммерческое предложение с подписями — тот документ, в котором есть коммерческое предложение и который отвечает за последующее фиксирование этих обязательств.
Функция зафиксировать обязательства — в этой функции компания, люди или организация, подписывает контракт, либо получает предоплату. К примеру, получение предоплаты по счету является акцептом договора оферты или же это вполне может быть просто обмен сканами документов. Можно сказать, что после этого поставщик обязуется уже по закону предоставить товар покупателю.
Далее продуцируется обязательство по доставке товара. Что это такое? Это документ, в котором фиксируются параметры доставки: что будет доставлено, куда будет доставлено и в каком количестве будет доставлено.
Поручение на выдачу товара — это поручение для склада о том, чтобы отгрузить этот товар получателю. Это может быть как экспедитор, так и непосредственно сам покупатель, приехавший за товаром на склад.
Потребность в товаре.После того, как мы с клиентом договорились и зафиксировали свои обязательства, значит, мы должны этот товар для него закупить. Мы фиксируем потребность в товаре. То есть это может быть либо документ, либо какая-то запись в базе данных, которая может так и называется — потребность в товаре, согласно которой будет заказан товар и в последующем отгружен и доставлен покупателю.
Функция сформировать потребность отвечает за то, чтобы исходя из потребностей в товаре сформировать потребность. То есть в чём смысл? Товар заказан, и мы обязались, что компания его отгрузит. Но ещё необходимо найти поставщика, необходимо определиться с ценой закупки и тому подобными вещами. Вот эта функция отвечает как раз-таки за формирование потребности.
После того, как мы сформировали потребность, нам необходимо найти поставщика. Найти поставщика — это функция, которая отвечает за то, чтобы исходя из потребностей товара найти того, кто будет отгружать в том количестве, в котором нам необходимо для последующей доставки этого товара покупателю.
Функция заказать потребность — отвечает за то, чтобы заказать потребность непосредственно у поставщика, после того, как он найден и потребность сформирована. Чаще всего это формируется в виде заказа поставщику, который размещается уже у поставщика.
Далее продуцируется планируемое поступление товара. Это может быть запись в базе данных, это может быть запись где-то ещё, либо запись в письменном виде, которая с в последующем необходима для того, чтобы по этому планируемому поступлению товара было зафиксировано поступление товара, и товар мог быть принят на склад в дальнейшем.
Принять товар от поставщика.Данная функция отвечает за то, чтобы товар, согласно планируемому поступлению товара, был принят на склад и размещен.
Функция разместить товар в месте хранения отвечает за то, чтобы после того, как мы приняли товар, мы его разместили для последующего хранения. Также эта функция отвечает за поддержание этого товара в надлежащем виде. То есть мы, допустим, постоянно проводим инвентаризацию, чтобы постоянно поддерживать информацию о товаре в актуальном состоянии.
Функция выдать товар получателю — отвечает за то, чтобы выдать товар получателю. Получатель может быть как экспедитор, как внутренний сотрудник организации, так и внешний по отношению к организации субъект. В частности, это может быть сам покупатель либо его доверенное лицо. Поэтому здесь важно отметить, почему это называется именно получатель. Получатель — это не обязательно покупатель, и их не нужно путать.
Функция запланировать доставку — отвечает за то, чтобы логист, исходя из графика доставки, исходя из количества товара, которое необходимо доставить, запланировал доставку на определенное время. Также эта функция отвечает за взаимодействие с покупателем и согласование с ним времени и параметров доставки. К примеру, если мы в функции продать товар назначили одно время, а покупатель не согласен, то в этой функции как раз-таки уточняется время, в которое покупателю возможно доставить заказанный товар.
Функция получить товар из места хранения — эта функция отвечает за то, чтобы, согласно поручения на выдачу товара, товар был получен для последующей доставки, перемещения и выдачи товара покупателю.
Переместить товар в место отгрузки. В данном случае эта функция отвечает за то, чтобы довезти товар до места выдачи товара покупателю. Здесь необходимо отметить следующее: если мы доставляем товар, то место выдачи — это не обязательно может быть покупатель, это может быть опять-таки доверенное лицо, либо это может быть точка выдачи, допустим, PickPoint. Соответственно, до неё, согласно маршруту, довозит водитель и отвечает за нее тоже он.
Функция выдать товар покупателю — эта функция отвечает за то, чтобы тот товар, который был перемещён покупателю, был выдан ему в надлежащем виде и количестве.
С уважением, Кинзябулатов Рамиль.
Комментарии (14)
LKU
09.04.2022 12:38Операционная деятельность любой торговой компании в основе своей - это два условно "встречных" потока - товаров и денег.
Можно придираться к представленной схеме в части описания товарных потоков, но не понятно, почему вообще потерялись деньги?
Там ведь целый мир, который при ближайшем рассмотрении не накладывается "1 в 1" на товарный поток. Например, торговая компания может вообще продавать товары клиентам с нулевой маржой, а прибыль зарабатывать на бэк-марже (выплатах от Поставщиков за достижение условий соглашений, прайс-протекшн и т.п.). И за заказ покупателя деньги может заплатить вовсе не он сам, а банк, например (кредит).
ramil_trinion Автор
09.04.2022 12:44Операционная деятельность любой торговой компании в основе своей - это два условно "встречных" потока - товаров и денег.
О потоках речь не идет, но вообще я скоро планирую дополнить модель функцией "распределение денег".
Можно придираться к представленной схеме в части описания товарных потоков, но не понятно, почему вообще потерялись деньги?
Как бы это не звучало непривычно, но деньги не самое главное в торговой организации. Самое главное - это товар, все остальное связано с распределением товара, но второстепенно.
Там ведь целый мир, который при ближайшем рассмотрении не накладывается "1 в 1" на товарный поток. Например, торговая компания может вообще продавать товары клиентам с нулевой маржой, а прибыль зарабатывать на бэк-марже (выплатах от Поставщиков за достижение условий соглашений, прайс-протекшн и т.п.). И за заказ покупателя деньги может заплатить вовсе не он сам, а банк, например (кредит).
Прибыль тут не причем, я же написал об этом.
DmitroQM
10.04.2022 18:161) Спасибо за статью, и спасибо за перевод стандарта, интересно для развития, надо многое обдумать, тем более что давно (года с 2000-го) рассказываю об этом подходе, но, похоже, не совсем корректно. Пример (даже не помню откуда взял текст для слайда):
"...Диаграммы IDEF0 предназначены для описания бизнес-процессов на предприятии и позволяют выявить формальные недостатки, что облегчает анализ деятельности предприятия.
Диаграммы строятся с использованием
графического представления: процессы в виде прямоугольника,
входы, выходы, управление, ресурсы,
вызовы – в виде стрелок..."2) Названия "функций" всегда резало слух.
Почему, например, "Продать товар" или "Продавать товар", а не "Продажа товара". Функция "Продажа товара" звучит как-то естественней на русском языке. А "глагольные формы" на английском (языке стандарта) отличаются от русского, так может и не надо "в лоб" переводить такой подход?
3) Контроль или Управление (стрелка)?
Контроль это пассивная деятельность, а вот управление активное воздействие на функцию, и контроль всегда где-то в конце, а управление идет от начала до конца выполнения функции и может в себя включать контроль. И обычно это документ, управляющий документ на функцию (инструкция или подобное).
Примеры из ГОСТ Р ИСО 9000:
3.3.7. управление качеством (quality control): Часть менеджмента качества (3.3.4), направленная на выполнение требований к качеству (3.6.5).3.3.10. управление изменениями (change control) <менеджмент конфигурации>: Действия по управлению выходом (3.7.5) после официального одобрения информации о конфигурации продукции (3.6.8).
4) Входы/вводы и выходы/выводы
Чет тут разницы не очень вижу, а привычней вход/выход. Мы же не электрические схемы описываем.
5) Интересно было бы увидеть вариант перехода от IDEF0 к BPMN для данного примера.
ZloyVampir
10.04.2022 20:59Почему, например, "Продать товар" или "Продавать товар", а не "Продажа товара". Функция "Продажа товара" звучит как-то естественней на русском языке.
Как Вы правильно понимаете, этот момент - совершенно не принципиальный. Вам использовать модель, соответственно, именно Вам и устанавливать правила именования функций. "Продажа товара" - выглядит естественнее, значит так и имеет смысл именовать.
Контроль или Управление (стрелка)?
По смыслу - управление. Это параметры, которые активно влияют на поведение функции.
Чет тут разницы не очень вижу, а привычней вход/выход. Мы же не электрические схемы описываем.
Обычно переводится именно как входы и выходы. А "ввод"/"вывод" - не более чем желание автора показать собственную значимость.
Интересно было бы увидеть вариант перехода от IDEF0 к BPMN для данного примера.
А зачем? Пример надуманный и абстрактный. BPMN широко применяется при описании бизнес-процессов. А вот IDEF0 - в практике не встречал. Самому интересно посмотреть на реальные модели, которые рисуются не ради модели, а для практического использования.
ramil_trinion Автор
11.04.2022 10:16Как Вы правильно понимаете, этот момент - совершенно не принципиальный. Вам использовать модель, соответственно, именно Вам и устанавливать правила именования функций. "Продажа товара" - выглядит естественнее, значит так и имеет смысл именовать.
Принципиальный. Название функции должно выражать предназначение функции это во- первых. К примеру: Продать товар говорит нам то функция предназначена для того чтобы продуцировать товар, в отличии от "продажи товара".
Название функции должно отражать законченное действие, то есть Функция "продать товар" если вывела товар и потребность в товаре, то она она выполнена и больше ничего от нее ничего не надо требовать.
По смыслу - управление. Это параметры, которые активно влияют на поведение функции.
Control и переводиться как "контроль". Так в стандарте.
Обычно переводится именно как входы и выходы. А "ввод"/"вывод" - не более чем желание автора показать собственную значимость.
Читайте перевод стандарта.
А зачем? Пример надуманный и абстрактный. BPMN широко применяется при описании бизнес-процессов. А вот IDEF0 - в практике не встречал. Самому интересно посмотреть на реальные модели, которые рисуются не ради модели, а для практического использования.
Почему же надуманный. Вам никто не мешает перейти от функции к процессу.
ramil_trinion Автор
11.04.2022 10:213) Контроль или Управление (стрелка)?
Контроль это пассивная деятельность, а вот управление активное воздействие на функцию, и контроль всегда где-то в конце, а управление идет от начала до конца выполнения функции и может в себя включать контроль. И обычно это документ, управляющий документ на функцию (инструкция или подобное).
Примеры из ГОСТ Р ИСО 9000:
3.3.7. управление качеством (quality control): Часть менеджмента качества (3.3.4), направленная на выполнение требований к качеству (3.6.5).3.3.10. управление изменениями (change control) <менеджмент конфигурации>: Действия по управлению выходом (3.7.5) после официального одобрения информации о конфигурации продукции (3.6.8).
Была бы моя воля я бы выкинул в помойку этот ГОСТ. Это извращение над оригиналом.
4) Входы/вводы и выходы/выводы
Привычней не значит правильно.
2) Названия "функций" всегда резало слух.
Почему, например, "Продать товар" или "Продавать товар", а не "Продажа товара". Функция "Продажа товара" звучит как-то естественней на русском языке. А "глагольные формы" на английском (языке стандарта) отличаются от русского, так может и не надо "в лоб" переводить такой подход?
Ответил тут
ZloyVampir
В чем ценность модели? Какой вопрос можно решить, глядя на модель?
Почему Вы решили, что универсальная модель может быть полезна? Ритейл - он тоже весь разный. И процессы везде разные. У вас в модели схема - сперва заказ, потом обеспечение потребности. Уверяю Вас, в реальности в большинстве случаев так не работает. Если это означает что-то другое, значит модель не отражает реальную картину.
ramil_trinion Автор
Потому что я сам использую ее на практике.
Процессы разные, функции одни и те же.
Нет там "сперва", там вообще нет времени.
Читайте выше.
ZloyVampir
Вы могли бы именно это и описать в статье. Каким конкретно образом используете модель. Например, мне это решительно непонятно.
Простите, нет. Функции тоже сильно разные. И без учета специфики конкретной организации - это бесполезный набор картинок.
Например, для розничной торговли принципиально нет функции "создать коммерческое предложение". Например, для работы в госсекторе обязательно должна быть процедура участия в тендере. Да и в ряде случаев в коммерческих организациях устраивается тендер. Например, торговля софтом имеет свои важные особенности, а автомобилями - свои. Но ваша функциональная модель, как универсальная, все это игнорирует. Также, есть малые предприятия, у них половина функций или в зачаточном состоянии, или отсутствуют вовсе. И их учет на таких предприятиях - излишнее усложнение. Или, наоборот, в крупных предприятиях появляются функции, которых принципиально нет в малых предприятиях, например, функции обеспечения безопасности, функции service desk, обеспечения работоспособности IT, юристы и многое-многое другое...
Да бог с ним! Давайте типично ритейловские функции? Управление ассортиментом? Ценообразозвание? Маркетинг? Работа с претензиями? Возвраты? У вас просто отсутствуют эти функции как класс!
Ну и потом. Модель - это язык. Ваша модель должна просто и наглядно донести какую-то мысль до потребителя информации. Например, у вас есть команда, и чтобы команда говорила на одном языке - предоставляете команде модель. И тогда, работая над, например, ТЗ, вы можете использовать модель...
Но модель должна быть адекватна автоматизируемому предприятию. Иными словами функциональная модель конкретного предприятия может принести пользу. Универсальная - это ничего не значащий набор картинок.
Есть там время. В виде отношения предшествования. Вход - функция - выход. Вы правильно писали, что читать модель нужно слева сверху, вправо вниз. Вот вам и время.
Например, у вас выход функции "продать товар" называется "потребность в товаре" и именно этот выход идет на вход функции "закупить товар". Т.е. вы здесь конкретно и прямо описали кейс, когда предприятие работает под заказ. Так бывает далеко не всегда. Во многих случаях закуп товара вообще не связан с заказами покупателей. И вы должны решить задачу как закупить столько товара, чтобы хватило покупателям с одной стороны и столько, чтобы не было затоваривания - с другой.
ramil_trinion Автор
Не у меня никаких входов и выходов как нет их и в нотации IDEF0, есть выводы и вводы. Почитайте мой перевод стандарта на русский, я специально в начале пишу об этой методологической ошибке, которая происходит из неправильного перевода слов input и output в нотации.
ZloyVampir
Да хоть горшком назовите, только в печь не ставьте.
И что меняет переименование "вход", "выход" во "ввод" и "вывод"? По мне - никакой разницы абсолютно.
Ваше переименование абсолютно не меняет исходный посыл: в вашей диаграмме обеспечение потребностей зависит от заказов. Т.е., как я и говорил дважды выше, сперва получаем заказ - потом его обеспечиваем.
И пример этот я приводил ровно к тому, что универсальная модель - бесполезна. Модель реального предприятия - может помочь.
По моим ощущениям, чтобы испытать пользу от моделирования конкретных предприятий, размер предприятия должен быть не ниже среднего.