Проблематика

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

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

В связи с этим я решил описать, то есть создать некую почти универсальную модель. Я к ней шёл уже, наверное, лет десять.Конечно, я не занимался ее разработкой все это время. Но уже  десять лет назад у меня были первые, скажем так, черновики такой модели.

Почему функции, а не процессы?

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

Почему именно функции? Потому что каждая из функций – это некий "черный ящик", и она может быть автоматизированна отдельно от других.  То есть в общей модели у нас есть функция. Далее мы выбираем нужную и сразу видим, что мы хотим получить, что мы имеем на входе, какое ПО для этого нужно использовать и чем руководствоваться. То есть то, что как раз написано в  стандарте IDEF0(перевод описания этого стандарта есть в моем блоге).

Как  читать модель

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

Что делать, если  за несколько функций отвечает один человек

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

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

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

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

А есть ли такая модель для  производственной организации? 

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

Можно ли сделать программное обеспечение на основе этой модели?

Да, можно. Я уже создавал ERP-систему для одной из организаций, которая построена по этому принципу. То есть я сначала описывал модель в IDEF0, а потом уже – - процессы в BPMN и, соответственно, автоматизировал, т.е. разработал программное обеспечение.

Вы также можете поступить подобным образом. При этом автоматизация может состоять из одной или нескольких программных систем.  К примеру, для функции «привлечь покупателя» или «продать товар» вы будете использовать какую-то маркетинговую или  CRM систему, а для  «отгрузить товар» вы можете использовать свою учётную систему или WMS-систему, в зависимости от того, что у вас есть, или что вы планируете использовать. С другой стороны, функции «продать товар» и "отгрузить товар" могут быть автоматизированы в одной учетной системе. Все зависит от ваших целей.

Как я давал названия

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

Модель

Диаграмм A-0

Диграмма A0

Привлечь покупателя

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

Продать товар

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

Закупить товар

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

Сохранить товар

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

Здесь необходимо отметить следующий момент. Почему называется получатель? Не покупатель, не клиент, не ещё что-то. Потому что получатель может быть, как покупатель, так и, к примеру, внутренний сотрудник, который получает  этот товар. Но он всё равно будет называться получатель. Это может быть получатель, который своими силами делает доставку, и это не покупатель получает, а ваш, допустим, экспедитор.

Доставить товар

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

Комментарии (15)


  1. forthuser
    28.02.2022 16:36
    +1

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


    1. ramil_trinion Автор
      28.02.2022 16:40

      Помогают ли все приведённые схемы бизнес-процессов

      Это функции, я не описывал процессы.

       привлечь покупателя к акту покупки товара производителя или банальное снижение цен на рынке таких же товаров более эффективная стратегия по активизации действий потребителя?

      Эта модель отражает функции организации внутри. Поведение потребителя в данной моделе не рассматривается.


  1. amarao
    28.02.2022 17:06

    Модели бывают двух видов: описательные и обладающие предсказательной силой.

    Описательная модель: пчёлка села на цветок, походила, полетала, вернулась в домик.
    Предсказательная модель: (дифур на 5 строк), аналитических решений не известно, числовая симуляция даёт совпадение модели и экспериментальных наблюдений с точностью 1-4%; при фиксации существующих (экспермиентально обнаруженных) параметров и прогноза погоды на следующий год будет +30±3 ульев, 2470±30 тонн мёда.

    Ваша модель какая? "Полетала, вернулась в домик" или с предсказательной силой?


    1. ramil_trinion Автор
      28.02.2022 17:10
      -2

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


      1. amarao
        28.02.2022 17:15

        Что полезного в вашей модели? Какую задачу она позволяет решить эффективнее. чем без неё?


        1. ramil_trinion Автор
          28.02.2022 17:17
          -2

          Чем полезна для Вас данная модель я сказать не могу. О пользе для себя я написал в начале статьи.


          1. amarao
            28.02.2022 17:20

            Вам оно и так интуитивно понятно, без модели. Кому ещё она полезна и почему?


            1. ramil_trinion Автор
              28.02.2022 17:25
              -1

              Вам оно и так интуитивно понятно, без модели.

              Что именно мне понятно без модели?

              Кому ещё она полезна и почему?

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


            1. mst_72
              28.02.2022 21:10

              Вообще-то SADT-методология и в частности IDEF0 нотация - шикарнейшее средство для описания процессов и ознакомления с ними неподготовленных пользователей. Не зря в свое время (как-минимум по легенде) в неё Пентагон вложился.

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

              Кроме того - минимум правил (вход, выход, инструкция, механизм, от 3 до 8 работ на одном листе). Шикарная вещь. Жаль только что из инструментов толком только BPWin и работает :(


    1. mst_72
      28.02.2022 21:22
      +1

      Это описательная модель. Раньше были инструменты по BPWIN моделям проводить функционально-стоимостной анализ. Насколько я знаю, этим особо никто не пользовался/не пользуется


  1. surVrus
    28.02.2022 22:49

    Странная модель.

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

    Архитектура всех моделей предприятий и корпораций: GERAM/TOGAF. ISO 15704:2000 Industrial automation systems -- Requirements for enterprise-reference architectures and methodologies Очень важный документ. В 2005 году добавили к нему аспект экономики.

    Ну или ISO/IEC 15288 System and software engineering — System life cycle processes и даже на русском языке ГОСТ Р ИСО/МЭК 15288-2005. Там все бизнес-процессы и все частные модели описаны.

    Описание моделей процессов периодических IEC 61512 Batch control Полная модель как правильно построить предприятие такого типа.

    Интеграция с ERP IEC 62264 Enterprise-control system integration Многоуровневая модель предприятия для целей интеграции. Полное понимание, как правильно построить процессы. Системы ERP связаны с этой моделью. На основе опыта разработчиков она построена и разработчики пользуются этой моделью. Связь в две стороны.

    Нужны стандартная, многомерная классификация для чего угодно? Берете IEC 81346, там все есть.

    Если же нужны детально проработанные модели до уровня SQL-запросов, с полным описанием всех тонкостей и нюансов - The Data Model Resource Book: A Library of Universal Data Models for All Enterprises, Len Silverston.

    Даже за 20 лет один человек не сможет построить хоть что-то близкое к этим стандартам. Да и зачем? Берите - пользуйтесь! Адаптируйте части, которые нужны для себя. И не морочьтесь на IDEF, это весьма кривая и старая методология. Да, для некоторых систем она когда-то годилась, но сейчас - это как на листке бумаги рисовать чертежи в 2Д, когда давно есть параметрическое трехмерное проектирование. Если же нужен конкретный код и готовая реализация - то есть для этого Apache Ofbiz. Не все там гладко, но как фреймворк для почти любого проекта - вполне годный. Да еще бесплатный, да еще работает на чем угодно.


    1. ramil_trinion Автор
      28.02.2022 23:01

      Вы пишите так как будто пытаетесь продать мне их)) Не надо. Все эти ваши Togaf и иже с ними не стоят бумаги на которой они написаны.


      1. surVrus
        01.03.2022 00:52

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

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

        Ну да ладно, каждому свое, я же не против.


  1. ZavLan
    01.03.2022 13:13

    Модель "Получить прибыль" должна выглядеть иначе: из полученной выручки уплатить налоги и вычесть издержки.


    1. surVrus
      01.03.2022 19:15

      Уже минимум лет 30 "Получение прибыли" от предпринимательской деятельности является одним из не самых важных бизнес-процессов. Обычно еще есть более важный "Увеличение стоимости компании" и несколько иных, не менее важных процессов. И есть еще куча нефинансовых показателей, которые обычно собирают под названием EVA, KPI и т. п.

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

      из полученной выручки уплатить налоги и вычесть издержки

      Тут тоже важно понимать, о какой прибыли идет речь. Есть EBITDA, есть EBIT, есть просто E. Есть маржинальный подход к расчету прибыли: там не все издержки учитываются напрямую. И так далее. Суть: ключевых показателей деятельности предприятия больше, чем 1. Например, "экономическая добавленная стоимость" - EVA гораздо лучше показывает состояние предприятия. Опять же, для краткосрочной перспективы важны одни показатели, для долгосрочной - немного другие. Есть финансовые, есть экономические показатели, и есть технические (технологические). И еще связи и зависимости между ними. Даже для торговли важны технологические показатели (хотя бы с уровня логистики), ведь где заканчивается ответственность за проданную продукцию? Хорошо, если за порогом офиса. А если нужно учитывать доставку до клиента, возвраты, сервис, гарантию и т.п. И это только веточка к покупателю. А точно такая же к Поставщику.

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