Находим взаимопонимание с заказчиками с применением Enterprise Architect

Публикация № 1253148

Управление - Управление взаимоотношениями с клиентами (СRM)

Enterprise Architect – мощное средство моделирования бизнес-процессов и информационных систем. Сергей Наумов на мастер-классе конференции Infostart Event 2019 Inception показал, как моделировать бизнес-процессы и составлять понятные заказчику документы при внедрении 1С-систем с помощью Enterprise Architect. Материалы мастер-класса будут полезны как разработчикам на платформе 1С, так и аналитикам, участвующим во внедрении.

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

Про моделирование на UML я рассказывал пару лет назад. Сейчас я опять вернусь к этой теме, но теории будет очень мало – будет в основном практика.

 

Зачем заниматься моделированием?

 

 

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

Но для меня моделирование – это не просто инструмент для процесса взаимодействия с заказчиком, для меня моделирование – это конкретный результат, который дает мне:

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

 

 

Давайте посмотрим на эту диаграмму. Что вы здесь видите? Это модель сказки «Репка».

Обратите внимание, что сама сказка «Репка» – это большой текст. А здесь в виде модели она представлена на небольшой диаграмме, которая передает весь смысл этой сказки.

Да, она более сокращенная, но, тем не менее, она дает вам представление об объекте и понимание того, о чем там речь – описывает всю последовательность действий.

Прочитав эту диаграмму, вы уже будете знать весь сценарий этой сказки.

 

Модель

 

 

Чтобы разобраться, что такое модель, мне нужно два добровольца из зала – Юрий и Сергей.

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

Модель нужна, чтобы находить взаимопонимание с заказчиком. При этом неважно, какую вы выберете нотацию описания. Изначально вы можете не знать, в какой нотации заказчику будет комфортнее воспринимать модель. Что такое нотация – мы сейчас рассмотрим.

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

 

Характеристики (что это)

Вес – 1.5 кг

Цвет – оранжевый

Форма – шар

Тип – овощ

Зачем оно (для чего)

Для приготовления каши

Для запекания

Для еды

Кто использует

Люди

 

Смотрите, Юрий выбрал текстовую нотацию и выработал некие параметры, по которым теперь можно описать любой овощ и составить его модель.

Теперь вернем Сергея – пусть он попробует угадать, какой объект был замоделирован.

Вопрос – почему нельзя в модели сразу написать, что это тыква?

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

Исключение составляют какие-то типовые процессы. Условно говоря, есть малая компания, у которой стандартный процесс выставления счета. Его можно не описывать.

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

Так вот, смотрите, что сделал Юрий. Он взял наш объект и выработал определенные проекции:

  •  первая проекция – характеристика этого объекта;
  •  вторая проекция – зачем это;
  •  третья проекция – кто использует.

Он спроецировал объект реального мира «на бумагу». Точно так же мы можем взять наше предприятие (предприятие, которое является для нас предметом или объектом нашего моделирования) и разложить его по определенным осям:

  •  оргструктура;
  •  бизнес-процессы;
  •  функции этого предприятия;
  •  цели и т.д.

То, как мы раскладываем объект моделирования по осям – это нотация. Юрий изобрел нотацию описания овощей.

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

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

 

Язык моделирования UML

 

 

Я применяю в своей практике UML – это очень удобный, на мой взгляд, язык для того, чтобы передавать знания.

Важно понимать, что UML – это не нотация, это язык. Он вам не объясняет, как разложить ваш объект по каким-то осям и как его представить. Язык UML – универсальный. В состав UML входит набор диаграмм, которые предназначены для описания разных аспектов поведения объекта либо его структуры.

  •  структура объекта – это часть объекта;
  •  а поведение – это как он действует или как он изменяется во времени.

 

Применение UML для практического моделирования

 

Давайте рассмотрим пару примеров практического применения UML.

 

 

Начнем с диаграммы пакетов.

На слайде приведено стандартное определение из википедии, что такое диаграмма пакетов:

«Диаграммы пакетов унифицированного языка моделирования (UML) отображают зависимости между пакетами, составляющими модель».

Когда я читал, что это и для чего, мне было совсем непонятно. Ввиду того, что UML – очень универсальный язык, большинство книг (обычно переводных) оперируют примерно такими терминами, которые не дают представление, зачем это.

На самом деле все просто. Пакеты – это определенные группировки тех или иных проекций (бизнес-процессов, участников бизнес-процессов и т.д.)

Вам понятно, что изображено на картинке справа? Я применяю эту диаграмму так, как мне удобно, и это вполне соответствует нотации.

 

 

Следующее определение – диаграмма вариантов использования. Это моя любимая диаграмма.

На некоторых форумах по UML годами продолжаются споры: «Что такое use case – функция или не функция?». Но мы с вами не будем разбираться – функция это или не функция: нет смысла тратить время как воинствующие теоретики на этих форумах. Для практического применения это не важно.

Давайте посмотрим определение:

«Диаграмма вариантов использования в UML – это диаграмма, отражающая отношение между авторами и прецедентами и являющаяся составной частью модели прецедентов, позволяющая описать систему не концептуальном уровне».

Я даже не буду читать это определение дальше – сразу видно, что оно неконструктивно.

На самом деле все очень просто:

  • Use case – это сценарий, порядок действий, на выходе которого реализуется определенная цель или появляется определенная ценность (value).
  • Цель, которую преследует автор (внешний по отношению к этому сценарию участник), или то, что он получит на выходе, обычно отражается в названии сценария.
  • Частный случай сценария – это бизнес-процесс, у которого есть выход и есть заказчик, который что-то хочет от этого бизнес-процесса.

 

 

Каждый сценарий в свою очередь мы можем расшифровать в последовательность действий. Обратите внимание, на UML очень удобно моделировать сразу:

  •  действия;
  •  объекты, которые в этих действиях участвуют;
  •  и кто эти действия выполняет.

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

 

 

Язык UML – расширяемый. Мы не обязаны применять диаграмму вариантов использования только с вариантами использования и с акторами (человечками), мы можем добавить на нее требования – я так делаю всегда, это очень удобно.

 

Кейс обработки требований заказчика

 

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

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

  1.  Базы данных на устройствах, использующиеся для инвентаризации, должны работать автономно (далее – автономные базы), т.е. без подключения к информационной сети организации.
  2.  В автономные базы должны выгружаться данные по ОС и номенклатуре, участвующих в инвентаризации.
  3.  Необходимо в мобильном приложении отражать состав составного объекта с возможностью отметки считывания штрихкода по составляющей части.
  4.  Необходимо протоколировать передачу данных в/из автономных баз в основную базу. Для протокола должна реализована возможность печати.
  5.  Необходимо фиксирования в автономных базах в составе данных о наличии объектов учета в соответствии с текущей учетной информацией. В автономной базе должна быть возможность указания составного объекта с указанием его местонахождения.
  6.  Необходимо в автономных базах фильтровать учетные данные по местам хранения.
  7.  Необходимо по завершению инвентаризации или по требованию пользователей обновить информацию о местонахождении объекта в основной базе.
  8.  Необходимо иметь возможность инвентаризации номенклатуры, имеющей количество более 1.

И приложение к протоколу:

  1.  Обеспечить формирование инвентаризационных ведомостей непосредственно в момент проведения инвентаризации, с возможностью:
  •  Контроля даты и времени считывания штрих кода
  •  Контроля излишних, недостающих и неисправных активов
  1.  Обеспечить возможность визуального информирования пользователя считывающего штрихкоды информацией параметров считанного актива
  2.  Обеспечить возможность поиска в мобильном устройстве
  3.  Обеспечить возможность в любое время вывода на экран мобильного устройства данных о проинвентаризированных объектах и оставшихся непроинвентаризированных объектах
  4.  Обеспечить возможность при повторном считывании штрихкода получать данные о дате, времени и месте предыдущего считывания штрихкода, с последующим подтверждением или отказом о внесении в инвентаризационные ведомости
  5.  Обеспечить синхронизацию программы инвентаризации на мобильном устройстве с основной базой
  6.  Обеспечить возможность получения отчета о результатах текущей инвентаризации в %.

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

Как я поступил, чтобы такой протокол обработать:

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

Обратите внимание, у меня не было ТЗ или какого-то формализованного документа. У меня просто была некоторая бумажка, которая определяет хотелки клиента.

Давайте на практике рассмотрим, как я такой протокол обрабатывал.

 

Формализация бизнес-процессов в Enterprise Architect

 

 

Для формализации бизнес-процессов я использую Enterprise Architect. Это та самая система, про которую мы сегодня общаемся. Я показываю все вживую:

  •  в левой части мы видим перечень объектов – это наш Project Browser (обозреватель объектов);
  •  и справа будут диаграммы.

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

 

 

Первое, что мы делаем – мы формализуем присланный протокол. Для этого вызываем пункт меню Publish – CSV – CSV Import/Export и загружаем файл протокола, сохраненный в csv.

 

 

В пакет «1.1. Требования протокола» загружаем первый csv-файл, а в пакет «1.2. Требования приложения» – второй.

 

 

Все наши требования протокола загружены в систему – теперь мы можем с ними работать как с объектами.

 

 

Мы открываем нашу диаграмму требований протокола, выбираем требования в дереве объектов и копируем их на диаграмму.

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

 

Обрабатываем требования протокола

 

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

Что мы хотим добиться, разбирая этот протокол:

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

Это позволит нам перейти от некоторого текстового непонятного описания к конкретике.

 

 

Рассмотрим первое требование. О чем нам говорит то, что базы данных должны работать автономно? Это значит, что у нас должен быть процесс обмена – сценарий (элемент с типом Use Case) «Обмен данными между основной информационной системой и автономными». Добавляем этот процесс на диаграмму и связываем его с нашим требованием (в группе Requirements Relationships находим пунктирную стрелку и соединяем блок требования с блоком процесса).

 

 

Следующее требование – в автономные базы должны выгружаться данные по ОС и номенклатуре. Это требование у нас также относится к процессу «Обмен данными между основной системой и автономными». Связываем требование с процессом.

 

 

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

  •  во-первых, его надо явно учесть в процессе обмена данными;
  •  и второе – у нас должен быть какой-то процесс сканирования объектов.

 

 

Смотрите, как интересно. Допустим, сейчас мы с вами работаем с требованиями и хотим понять – мы вообще все требования обработали или не все?

Мы можем открыть матрицу отношений (в меню Design – Matrix – Open as Source).

 

 

Здесь нам нужно выбрать:

  •  в качестве источника (Source) – пакет наших требований;
  •  а в качестве цели – существующие в системе бизнес-процессы (они у нас сейчас в пакете «2 Состав процессов»).

Смотрите, мы получили матрицу.

  •  У нас в левой части требования, с которыми мы работаем.
  •  А справа мы видим, с какими процессами эти требования соотносятся, то есть, какие процессы получились из требований.

Кстати, в прошлом году, когда я показывал такую матрицу на выступлении по бюджетированию, меня несколько слушателей отдельно попросили рассказать про Enterprise Architect. Отсюда и родилась идея этого мастер-класса.

 

 

Идем дальше. Четвертое требование – необходимо протоколирование передачи данных из автономной базы в основную. И должна быть реализована возможность печати.

  •  Очевидно, что это требование у нас соотносится с процессом обмена (протоколирование).
  •  А для процесса печати мы с вами добавляем новый элемент типа Use Case в пакет «2. Состав процессов».

 

 

Новый процесс мы добавляем из набора элементов Use Case (вызывается из меню панели Toolbox). А для требований мы используем набор элементов Requirements.

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

 

 

Здесь можно видеть, сколько нотаций поддерживает Enterprise Architect.

 

 

Следующее требование – необходимо фиксировать в автономных базах данные о наличии объектов учета в соответствии с текущей учетной информацией:

  • в автономной базе должна быть возможность указания составного объекта с указанием его местонахождения – очевидно, что это опять же касается обмена;
  • и при сканировании мы должны указать местонахождение (т.е. делаем привязку к процессу сканирования).

 

 

Следующее требование – необходимо в автономных базах делать фильтрацию учетных данных по местам хранения.

  • Для этого требования у нас должен быть определенный сценарий «Анализ и поиск объектов». Причем при поиске объектов, очевидно, что дальше мы захотим просканировать найденный объект. Соответственно, у нас сценарии «Сканирование» и «Анализ и поиск объектов» между собой связаны. И эта связь здесь у меня сразу задана как расширяемая («Extend») – у нас есть сценарий поиска объектов и подсценарий в нем сканирования объектов (отмечаем, что эти сценарии связаны).

 

 

Следующее требование – необходимо по завершению инвентаризации или по требованию пользователей обновить информацию о местонахождении объекта в основной базе. Очевидно, что это относится к обмену.

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

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

 

Обрабатываем требования приложения к протоколу

 

 

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

 

 

Давайте разберемся.

  • Первое требование – обеспечить формирование ведомостей непосредственно в момент проведения инвентаризации с возможностью контроля даты и состояния остатков. Это требование связано с процессом «Анализ и поиск объектов». Должна быть какая-то инвентаризационная ведомость, где мы видим все, что просканировали.
  • Еще одно требование – обеспечить возможность визуального информирования пользователя, считывающего штрихкоды. Это требование связано с процессом «Сканирование объектов» (причем, при его добавлении сразу появляется расширяемая связь между процессами «Анализ и поиск объектов» и «Сканирование объектов»).
  • Следующее требование – обеспечить возможность поиска в мобильном устройстве. Добавляем связь с процессом «Анализ и поиск объектов».

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

 

Добавляем связи на объекты

 

 

Дальше – нам нужно от сценариев перейти к конкретным объектам информационных баз.

  • Какие объекты системы нам понадобятся для сценария «Обмен данными между информационной системой и автономными базами»?
    • во-первых, нам понадобится обработка «Рабочее место мониторинга обмена»;
    • во-вторых, очевидно, что нам, по всей видимости, понадобится какой-то механизм запуска инвентаризации, чтобы пошел обмен с мобильным устройством – документ «Распоряжение на запуск процесса инвентаризации» копируем сюда же, связываем с процессом, и мы уже видим, что у нас есть определенное распоряжение, которое связано с этим процессом.
  • Для сценария «Сканирование» нам, скорее всего, понадобится какая-то обработка сканирования объектов («Обработка сканирования и подбора объектов»).
  • И для сценария «Анализ и поиск объектов» нам понадобится «Рабочий стол мобильного приложения».

Вот так мы укрупненно накидываем наши метаданные.

 

 

Смотрите, наша модель дополняется:

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

 

Описываем роли с помощью диаграммы Use Case

 

 

Что мы еще здесь можем получить?

Мы можем спроектировать роли людей, которые будут работать с нашей системой. Я показывал уже эту диаграмму – мы располагаем на отдельной диаграмме все наши бизнес-процессы:

  •  говорим, что для запуска процесса инвентаризации нам нужен главный бухгалтер;
  •  пользователь автономной системы будет сканировать, искать объекты, заниматься печатью;
  •  кроме этого, у нас будет еще один участник процесса, который мы автоматизируем – это «Основная система», которая упоминается в протоколе.

Слева на диаграммах вариантов использования принято изображать непосредственно участников сценария, а справа – внешних участников сценария, к которым этот сценарий обращается:

  •  наш сценарий обмена данными обращается к основной информационной системе – поэтому она справа;
  •  а человек, который сканирует – он внутри процесса, поэтому он слева.

 

Детализируем каждый процесс с помощью диаграммы активности UML

 

 

Дальше мы начинаем уточнять наши требования: у нас есть процесс сканирования объектов. Чтобы его уточнить, мы начинаем расписывать уже конкретный сценарий, строить конкретный порядок действий – последовательность действий, как мы будем работать с этой системой.

 

 

Мы добавляем для процесса сканирования объектов дочернюю диаграмму.

 

 

Мы поместим наш бизнес-процесс сканирования объектов в отдельную папку «Бизнес-процессы» и начинаем строить нашу модель.

 

 

Теперь вернемся к диаграмме состава процессов, поставим курсор на элемент «Сканирование объектов». Теперь мы связываем его с диаграммой сканирования объектов (выбираем в контекстном меню New Child Diagram -> Select Composite Diagram -> выбираем диаграмму «Сканирование объектов»).

 

 

Теперь на элементе процесса появились «очки», и наша модель становится интерактивной – мы можем от элемента перейти непосредственно к расшифровывающей диаграмме.

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

 

 

Начинаем строить нашу модель сканирования объектов. Первое, что мы делаем, мы добавляем наши полоски (в контекстном меню диаграммы пункт Swimlanes and Matrix).

 

 

Я обычно добавляю следующие полоски:

  •  Вх.вых. (входящая и выходящая информация);
  •  Деятельность;
  •  Ответственный;
  •  и Требования.

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

 

 

Начинаем моделировать. Мы моделируем с помощью диаграммы активности UML. Диаграмма активности – это просто порядок действий.

Добавляем активности:

  • начало процесса;
    • поиск непросканированного объекта в МП:
    • очевидно, что у нас есть некоторая обработка, которую мы используем для того, чтобы этот объект найти – мы связываем наше действие и эту обработку;
  • сканирование объекта делает пользователь автономной системы – обратите внимание, я на каждой диаграмме использую уже готовый элемент, новых не создаю;
  • следующая активность – сканирование;
  • связываем наши элементы и завершаем процесс.

Это очень простой процесс. Я специально его привел для примера. Когда мы с вами были в требованиях, мы набрасывали укрупненные объекты метаданных. Мы еще не могли себе предположить всех наших детальных объектов, которые нам потребуются в этом процессе.

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

 

 

И здесь как раз появляется документ «Регистрация сканирования объекта».

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

 

Связываем диаграмму активности UML с первоначальными требованиями

 

 

Далее – мы начинаем разбираться, все ли требования мы учли в рамках этого процесса сканирования объекта. Мы можем в контекстном меню выбрать пункт Find -> Find in all Diagrams.

 

 

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

Переходим в нашу диаграмму, и копируем в нее все связанные требования.

 

 

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

 

 

Дальше здесь можно связать требования с конкретным процессом (вызывав в наборе элементов Activity элемент Dependency), но мы, чтобы не загромождать диаграмму, эту стрелку скрываем (мы ее скрыли, но можем построить матрицу трассировки, как я показывал ранее).

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

 

Строим диаграмму Ганта для планирования работ по проекту

 

 

Смотрите, что самое интересное – у нас появился набор объектов метаданных. Теперь мы можем для этой папки в контекстном меню вызывать View as Gant. У нас появилась диаграмма Ганта. Здесь мы можем вызвать панель назначения ресурсов, добавить аналитика, разработчика.

 

 

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

Да, это не MS Project, здесь не так все функционально, здесь нет возможности хранения базовых версий планов, их сравнения и т.д. Но для большинства наших проектов этой функциональности достаточно.

 

Генерируем документацию

 

 

После того, как мы построили нашу модель, самое интересное – у нас есть требование, есть состав процессов, есть наши объекты метаданных и бизнес-процессы, мы можем сделать какое-то описание наших объектов (например, для документа «Распоряжение на запуск процесса инвентаризации» укажем, для чего предназначен этот документ).

 

 

И сделаем очень интересную штуку: Publish – Report Builder – Generate Documentation.

 

 

Выбираем путь к файлу и нажимаем кнопку Generate.

 

 

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

 

Вопросы:

 

  • Вы показали на примере десятка требований, пары пользователей, нескольких функций и отчетов. А какой в вашем опыте был максимальный объем объектов, которыми вы управляли через Enterprise Architect в какой-нибудь масштабной разработке?
  • Наверное, самый масштабный был с несколькими десятками верхнеуровневых требований. По объектам не вспомню. Но они очень здорово по диаграммам бьются. Я специально сделал два пакета, потому что на одну диаграмму, если даже десяток требований вывалить, будет очень непонятно. Вы их просто бьете по пакетам (декомпозируете), и вполне можно работать.
  • Как вы предлагаете это использовать в жизни? Для каких целей и задач? В каких контекстах имеет смысл настолько заморачиваться – обеспечить трассировку требований, взаимосвязи, непротиворечивость и еще много чего? Насколько это нужно? Когда внедряется типовая система, идет ее доработка, кастомизация какая-то, и разработчик сильно связан с этой типовой системой – мне кажется, что бесполезно перетаскивать и описывать процессы в первую очередь самой типовой системы. Потому что, если переложить в эту архитектуру ERP (взять и использовать вместо СППР Enterprise Architect) – потом же не разберешься, будет слишком много всего. Мне кажется, Enterprise Architect интересен тогда, когда новые блоки системы создаются практически с нуля – со слабой взаимосвязью с типовой системой. Какой у вас опыт использования Enterprise Architect, когда речь идет о доработке типовой системы и разработке на ее основе?
  • Когда я внедряю типовую систему, я в любом случае делаю описание к процессам. Я его делаю в этой нотации. Да, просто модель из двух пакетов: состав процессов и сами бизнес-процессы. Когда мы идем в проект, я всегда делаю описание процессов. Поэтому очень прекрасно ложится
  • Но описание процессов – это не все, что вы показывали. Вы показывали еще и связь с объектами метаданных.
  • Да, я здесь показал по максимуму, с учетом разработки. Но когда мы делаем описание типовой конфигурации, есть процессы основные – для них нужно делать модель, потому что они вариативные. А есть вспомогательные процессы (например, основные средства) – они у всех одинаковые. Поставьте кружочек, напишите «Учет основных средств» и хватит. А то, где могут быть варианты, потому что одна компания сначала выставляет счет, а потом оформляет заказ. Другая – сначала делает заказ, а потом выставляет счет. Все эти варианты прекрасно описываются в виде процессов.
  • Процессы – бесспорно. К тому же для процессов есть нотации более читабельные для заказчика (вроде BPMN). Вопрос – связываете ли вы моделирование с проектировкой системы, когда речь идет о внедрении типовых прикладных решений?
  • Когда внедряются типовые решения, доработки все равно возникают. Поэтому мы тут описываем процессы, и здесь же у меня появляются требования, доработки. На текущем проекте мы и требования собрали, и те доработки, которые выявлялись в ходе обсуждения. Мы прямо брали эту модель и обсуждали ее. У меня был отдельный пакет – доработки, которые я выявил, доработки, которые заказчик просил. И отдельный пакет с задачами. Я открываю модель на совещаниях, и мы идем по этой модели – очень удобно было общаться и фиксировать договоренности. Хотя проект был по бюджетированию, там доработок было немного. По поводу диаграммы BPMN – создаете новую диаграмму, указываете, что при ее описании используется набор элементов BPMN2, и рисуете.
  • Я правильно понимаю, что опять приходится рисовать, что Activity-диаграммы и диаграммы BPMN живут своей жизнью и автоматически не могут быть трансформированы?
  • Нет, мы работаем с диаграммами BPMN вручную, мы их не трансформируем.
  • Вы в своей практике не опускаетесь до уровня метаданных, не описываете реквизиты, модули, роли системы?
  • Я делаю верхнеуровневое моделирование – ровно так, как я показал.
  • Только требования, бизнес-процессы и диаграммы вариантов использования? А проектирование системы вы здесь не выполняете?
  • Частично выполняю. У меня есть описанная нотация моделирования, я пробовал опускаться до метаданных, заставлять разработчиков описывать основные алгоритмы. Например, у нас появляется объект метаданных – мы можем описать его функцию. На основании одного объекта метаданных мы можем ввести другой объект метаданных. Мы их можем друг с другом связать по каким-то правилам. Я пробовал это делать. Но для проектов автоматизации типовых внедрений это избыточно. Это долго, дорого и никакой ценности не несет. Когда ты даешь программисту процесс и говоришь: «Я хочу получить этот процесс» – у нас ребята все понимают.
  • Как в Enterprise Architect можно отразить отклонения – что не должно быть, но может быть. У меня на каждом шаге, после которого появляется некий материальный результат, он может не появиться. Я могу просканировать – не просканировалось. Я могу начать искать объект – не нашел. Что я должен делать, и как это можно отразить, чтобы можно было понять, к чему эта штука относится? Вы показали прямую дорогу – необходимое и достаточное, если все в порядке. Как это отразить, если не все в порядке?
  • Тут есть классическое решение. Добавляем ветку «Не все в порядке» и возвращаемся в начало. Или вы можете добавить сюда еще одну дорожку с названием «Регламент на случай, когда что-то пошло не так» и вставить объект напротив того действия, когда что-то пошло не так. Это не жесткая система, она не обязывает вас выполнять какие-то определенные шаги. Она позволяет построить некоторую нотацию, с помощью которой вы делаете модель вашей системы. Я для себя использую такую нотацию, а вы можете покреативить – сделать для себя отдельную дорожку и покрасить ее элементы в красный цвет, чтобы выделить разрывы.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Оставьте свое сообщение

См. также

Как настроить правильную техподдержку (helpdesk, service desk на коленке) Промо

Управление услугами и сервисом Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Монитор заказов Учет рабочего времени v8 УУ Бесплатно (free)

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

24.04.2019    15824    0    siddy    0    

Что такое качество разработки и качество поддержки? Статья 2

Методология управления разработкой Проектирование Бесплатно (free)

Это вторая из 8 статей про разработку в сфере 1С. В данной статье будут раскрыты следующие вопросы: 1. Ошибки в решениях в пользовательском режиме и их причины. 2. Технические ошибки при разработке решений в 1С. 3. Мы закрыли 100 заявок за 1 день. Есть ли польза от такой поддержки? Польза или вред от SLA.

30.06.2020    642    0    biimmap    5    

Кто такой архитектор? Системный или функциональный? Статья 1

Конфигурирование 1С Проектирование Бесплатно (free)

В связи с повальным непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. Она очень актуальна, т.к. многие проектные команды не имеют архитектора, либо используют его не по назначению. В этой статье раскрываю роль архитектора и его значимость. Основываюсь на своём опыте (более 10 лет), также изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд. В данной статье будут раскрыты следующие вопросы: 1. Кто такой архитектор? 2. Какие задачи выполняет архитектор? 3. Можно ли без него обойтись? 4. Чем отличается системный архитектор от функционального архитектора? 5. Кто главный: РП или архитектор? Кому подчиняется проектная команда?

30.06.2020    2780    0    biimmap    47    

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

Техническое задание Бесплатно (free)

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

28.05.2020    6716    0    sapervodichka    69    

Как мы визуализировали отдел продаж - графические отчеты для 1С Промо

Управление взаимоотношениями с клиентами (СRM) Пользователю системы Управление взаимоотношениями с клиентами (СRM) v8 УНФ ERP2 УТ11 КА2 1С:CRM Россия УУ Бесплатно (free)

После выполнения очередного проекта по автоматизации отдела продаж на 1С (конфигурация 1C:CRM 8, ред. 2.0) мы вдруг поняли, что чего-то не хватает. Странно: вроде и бизнес-процессы внедрены, и цифры в отчетах бьются, и заказчик в целом доволен. Но, реальным финалом проекта должна была стать визуализация данных по отделу продаж и установка TV-панели в кабинете у менеджеров по продажам.

05.09.2017    38269    0    alexrovich_ru    56    

Конструктор Бизнес-Процессов. Подсистема/Конфигурация/Расширение

Управление бизнес-процессами (BPM) v8 1cv8.cf Бесплатно (free)

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

25.05.2020    3572    0    YuriYuriev    23    

RPA (роботизация) – "костыль" или автоматизация будущего? Идеи и практические примеры

Проектирование Бесплатно (free)

Автоматизация действий пользователя упрощает интеграцию с внешними системами, сокращает рутинную работу, делает бизнес-процесс более контролируемым. О подходе Robotic Process Automation (RPA), случаях, когда его можно использовать, существующем рынке RPA-систем, на конференции Infostart Event 2019 Inception рассказал CTO компании WiseAdvice Олег Филиппов.

10.03.2020    3912    0    comol    1    

1С СППР, как инструмент по внедрению, разработке и сопровождению информационных систем

СППР Управление проектом Бесплатно (free)

Система проектирования прикладных решений (СППР) – инструмент от фирмы «1С», который позволяет проектировать конфигурации, вести по ним полную документацию в разрезе объектов системы, собирать требования на реализацию и выдавать на их основе детально описанные задачи программистам. Как правильно использовать СППР при работе с многосоставной командой, на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «Иритум» Роман Кальмансон.

09.01.2020    5710    0    roman72    0    

IDEF0. Знакомство с нотацией и пример использования Промо

Управление бизнес-процессами (BPM) Обучение, бизнес-тренинг, курсы 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

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

28.06.2017    29830    0    raiml    36    

1С: СППР и оценка сроков и стоимости проектов методом COCOMO II

Проектирование 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

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

06.01.2020    3353    0    roman72    9    

Простейший пример создания бизнес-процессов

Практика программирования Управление бизнес-процессами (BPM) v8::Бизнес-процессы 1cv8.cf Бесплатно (free)

Простой пример создания бизнес-процессов в несколько шагов. Может пригодиться при первом знакомстве с ними или для решении задач экзамена 1С:Специалист по платформе.

20.11.2019    12519    0    YPermitin    17    

Vanessa Automation + СППР

Vanessa Automation СППР v8 Бесплатно (free)

Vanessa Automation. Использование автоматизированного тестирования в СППР.

07.11.2019    10914    0    SvVik    14    

Краткое описание BPMN с примером Промо

Управление бизнес-процессами (BPM) Бесплатно (free)

О том, что такое BPMN, написано очень много. Но проблема в том, что почти вся информация, которую можно найти в Интернет, ориентирована на людей, которые уже ранее сталкивались с BPMN или с другим стандартом моделирования бизнес-процессов. Я же предлагаю разобраться «с нуля» — что такое BPMN? В чем особенности и преимущества этой технологии и почему она появилась и оказалась столь востребованной, по крайней мере, за рубежом. Да и у нас в стране ей все больше и больше интересуются.

28.06.2017    29065    0    raiml    10    

Коммуникация и клиент

Управление взаимоотношениями с клиентами (СRM) Личная эффективность Бесплатно (free)

«Пока слова не отражают суть вещей, успеха в делах не будет». Аристотель.

11.10.2019    4129    0    Шёпот теней    4    

Мастер-класс СППР

Управление проектом СППР Бесплатно (free)

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    10550    0    SergeyN    6    

Как создать идеальную службу поддержки бизнеса

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

О том, насколько хорошо работают бизнес-процессы, можно понять по реакции пользователей: если они довольны - значит, все хорошо. А что является главным связывающим звеном между бизнесом и пользователями? Конечно, служба поддержки, и чем лучше вы организуете ее работу, тем удовлетворенность пользователей будет выше. О том, что как создать идеальную службу поддержки, на конференции INFOSTART EVENT 2018 Education рассказал Сергей Харитонов из ГК «Агат».

26.07.2019    4705    0    user1063453    0    

Про спагетти, или как исследовать бизнес-процессы организации Промо

Техническое задание Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в "слепом" режиме управления?

23.02.2017    27016    0    Gavrik    10    

Impact mapping: чем он может быть вам полезен

Техническое задание Бесплатно (free)

Привет, коллеги! Сегодня хочу поговорить про один из инструментов Владельца продукта - Impact mapping (карта влияния). Чем он хорош и почему его стоит использовать.

26.07.2019    6146    0    slozhenikin_com    14    

Как привлечь пользователей на портал самообслуживания

Управление бизнес-процессами (BPM) Бесплатно (free)

Зачем нужен портал самообслуживания? Как заставить пользователей подавать обращения через портал самообслуживания? В данной статье руководитель службы технической поддержки делится своим опытом и выводами по запуску портала самообслуживания.

09.06.2019    4344    0    KoldunOne    6    

[История разработки] Терминал путевых листов (АвтоГРАФ 5)

Практика программирования Управление бизнес-процессами (BPM) v8 1cv8.cf Бесплатно (free)

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

30.05.2019    9576    0    rpgshnik    16    

Как оценивать задачи программисту 1С Промо

Техническое задание Россия Бесплатно (free)

Оценивать задачу всегда сложно. У меня не всегда получается оценивать задачи адекватно (во всяком случае, не всегда моё ощущение адекватности совпадает с ощущениями других участников процесса). Именно по причине того, что вопрос для меня актуальный, хочу поделиться своими размышлениями, субъективным опытом в этом вопросе. Речь пойдет только о технической оценке.

11.08.2016    32940    0    SamBadi    52    

Уволен через автоматизацию

Управление бизнес-процессами (BPM) Бесплатно (free)

Кейс бизнес-программирования

07.03.2019    10688    0    1c-intelligence    47    

Принципы проектирования справочников номенклатуры в 1С: Управление Предприятием 2 (ERP 2.4.6)

Управление бизнес-процессами (BPM) Бухгалтерский учет Пользователю системы v8 ERP2 Россия Бесплатно (free)

Принципы системного подхода к проектированию справочников номенклатуры в 1С: Управление Предприятием 2 (ERP 2.4.6) или как избежать замусоривания.

13.02.2019    21782    0    roman72    28    

Практические вопросы внедрения и развития автоматизации склада. Часть 2 Промо

Управление бизнес-процессами (BPM) Оптовая торговля Оптовая торговля 1С:Франчайзи, автоматизация бизнеса УУ Бесплатно (free)

Слайды к докладу на секции "Складские технологии" в малом зале на IEE-2013. Пример автоматизации склада по "бюджетному" варианту с использованием ТСД+RDP.

26.03.2015    31232    0    CheBurator    33    

Где мы взяли флакон?

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

История появления и развития методики

26.12.2018    9278    0    1c-intelligence    7    

Айсберг, кейсы

Управление бизнес-процессами (BPM) Бесплатно (free)

Несколько примеров применения принципа "Айсберг".

26.12.2018    7367    0    1c-intelligence    12    

Методология управления изменениями на основе методологии TOGAF и языка моделирования Archimate

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

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

02.12.2018    8697    0    rossoxa    2    

Конфигурация: Автоматизация работы ИТ-отдела Промо

Финансовый учет и бюджетирование (FRP) Управление взаимоотношениями с клиентами (СRM) Документооборот и делопроизводство Управление персоналом (HRM) Управление холдингом (CPM) Учет ОС и НМА Учет рабочего времени Управленческий учет (прочее) v77::ОУ ИТ-компания УУ Бесплатно (free)

Конфигурация предназначенная для автоматизации работы ИТ-отдела. На данный момент реализованы блоки учета бюджетирования, оборудования, кадровый учет, учет расходных материалов и программного обеспечения и т.д. Программный комплекс "Аристотель" предназначен для автоматизации деятельности подразделений информационных технологий, и ориентирован в первую очередь на руководителей ИТ–подразделений малого и среднего бизнеса, но также может использоваться для решения определенных задач и в рамках более крупных организаций. На основе ролей для каждого сотрудника, как ИТ–подразделения так и внешнего бизнес-подразделения организуется полноценное рабочее место со своим уровнем доступа. Програмный комплекс построен на широко распространенной платформе 1С:Предприятие.

30000 руб.

18.02.2008    49910    9    232    

Похороны скрам-доски

Управление бизнес-процессами (BPM) Личная эффективность Бесплатно (free)

Продолжаем балансировать позитив Марии Темчиной. Вторая глава книги про американцев.

31.10.2018    8718    0    1c-intelligence    15    

Описание, синхронность и "один-много"

Управление бизнес-процессами (BPM) Бесплатно (free)

Продолжаем смотреть на процессы глазами программиста.

09.10.2018    9451    0    1c-intelligence    36    

Как теряют бизнес. Реальные истории от бизнес-консультанта. Промо

Управление бизнес-процессами (BPM) Управление проектом Бесплатно (free)

Поговорить о том, какие причины способствуют гибели существующего и часто даже успешного на определенном этапе бизнеса, я планировал давно, но все не доходили руки. Но недавно я услышал о банкротстве моего, теперь уже, клиента. Именно этот факт стал для меня неким толчком. Я осознал, что именно сейчас, в условиях кризиса очень важно понимать, почему бизнес может окончиться крахом и учиться избегать подобных ситуаций. Как известно, когда в экономике кризис, любой бизнес ослаблен. Если сравнивать с человеческим организмом, то кризис для экономики – как ослабление иммунитета. Когда человек здоров, то мелкие болезни проходят незамеченными. Организм сам справляется с проблемами, а в случае ослабления иммунитета, любая инфекция может привести к серьезным заболеваниям или даже стать фатальной. Так происходит и в бизнесе. Если в период подъема экономики какие-то недостатки конкретного бизнеса сглаживаются, остаются незамеченными и даже не слишком мешают работать, то в периоды экономического спада они становятся теми самыми «тонкими местами», которые приводят к снижению прибыли, к определенным проблемам, а иногда даже к полному краху всего бизнеса.

06.04.2015    37312    0    raiml    14    

Проектирование архитектуры и модификация программных продуктов как технология в сложных проектах системной интеграции и автоматизации на базе 1С: СППР

Управление проектом Интеграция СППР v8 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Как сделать проектирование функциональной архитектуры ПО технологией. Цель - устранить ряд типовых проблем на сложных проектах. Как использовать для решения этих задач 1С система проектирования прикладных решений (СППР). Статья полезна для директоров франчайзи, системных интеграторов, руководителей проектов, архитекторов и консультантов.

03.10.2018    15792    0    roman72    19    

Цифровая трансформация.

Управление бизнес-процессами (BPM) Бесплатно (free)

Цифровая трансформация. Что это и как мы можем помочь нашим клиентам?

21.08.2018    5665    0    -DenA-    4    

Управление отделом разработки с помощью "1С:СППР"

Управление проектом СППР v8 Бесплатно (free)

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

20.08.2018    15422    0    pau74    11    

Принцип "Айсберг"

Управление бизнес-процессами (BPM) УУ Бесплатно (free)

Простой принцип, который стоит учитывать при автоматизации.

16.08.2018    12318    0    1c-intelligence    23    

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

Техническое задание Управление бизнес-процессами (BPM) Бесплатно (free)

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

14.08.2018    7239    0    itriot11    42    

Склад Готовой Продукции – отказать, прямое распределение. Промо

Управление бизнес-процессами (BPM) Оптовая торговля, дистрибуция, логистика УУ Бесплатно (free)

Данная статья описывает методику складского учета без использования склада готовой (СГП) продукции или центрального склада. Сразу скажу – это я немного лукавлю, но так или иначе факт – в 3 крупных компаниях, где применили эту методику – СГП больше нет. Цель данной статьи – познакомить читателя с методикой, применимой как в производстве, так и в оптовой торговле.

27.02.2015    26233    0    izidavld    69    

Автоматизация контроля границ

Управление бизнес-процессами (BPM) Бесплатно (free)

Продолжаем изучение учебника по бизнес-программированию. На этот раз - параграф из раздела "Автоматизация".

08.08.2018    9559    0    1c-intelligence    18    

Канбан в условиях российской действительности

Управление бизнес-процессами (BPM) Управление проектом Россия Бесплатно (free)

Слово "Канбан" слышали все, кто работает в производстве, в поддержке и в ИТ-разработках. В этой статье я попробую рассказать про Канбан подробно, обобщить принципы и опыт (мой и ближайшего окружения) по внедрению на практике этой системы с упоминанием возникающих при этом "граблей" и рекомендаций по борьбе с ними.

08.08.2018    21732    0    MariaTemchina    64    

Метод плавательных дорожек

Управление бизнес-процессами (BPM) Бесплатно (free)

Простой метод анализа процессов

02.08.2018    12124    0    1c-intelligence    60    

Автоматизация бизнес-процессов как способ выявления потерь производства Промо

Управление бизнес-процессами (BPM) Бесплатно (free)

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

09.12.2013    22334    0    pro-rok    15    

Как увеличить лояльность со стороны клиентов

Бухгалтерия Управление взаимоотношениями с клиентами (СRM) Управление взаимоотношениями с клиентами (СRM) Россия БУ Бесплатно (free)

Сейчас на рынке много компаний, которые оказывают услуги по ведению бухгалтерского учета. В большинстве из них работают профессионалы, поэтому качество услуг будет примерно одинаковым. Но вот вопросы коммуникации с заказчиками можно решать по-разному. Я, специалист Ассоциации профессиональных бухгалтеров, хочу поделиться своим опытом. Для работы с клиентами наша компания использует специально разработанное мобильное приложение «АПБ».

30.07.2018    5192    0    user1021263    3    

Миф о всесильном менеджере

Управление бизнес-процессами (BPM) Бесплатно (free)

Не будем заниматься изменениями, потому что мы - не менеджеры.

05.07.2018    8947    0    1c-intelligence    1    

Эсперанто, эльфийский и клингонский

О жизни Управление бизнес-процессами (BPM) Личная эффективность Бесплатно (free)

Почему бизнес и ИТ не понимают друг друга? И как сделать, чтобы понимали?

14.06.2018    11309    0    1c-intelligence    47    

ГОСТ 34.602-89. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ Промо

Техническое задание Россия Бесплатно (free)

Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее - ТЗ на АС). Дата введения с 01.01.1990г

29.06.2005    36347    0    support    11    

Продукт vs Процесс

Управление бизнес-процессами (BPM) УУ Бесплатно (free)

Продолжаем тему управления качеством, рассматривая ключевой акцент - продукт или процесс?

08.06.2018    12008    0    1c-intelligence    40    

Экспансия решений 1С на глобальный рынок: как взять быстрый старт?

Управление бизнес-процессами (BPM) Управление проектом 1С:Франчайзи, автоматизация бизнеса Бесплатно (free)

Николай Шилкин рассказал о требованиях, которые предъявляет глобальный рынок к решениям 1С, рассмотрел достоинства и недостатки платформы в контексте ее выхода за пределы рынка стран СНГ. Он также объяснил, у каких решений есть шансы добиться успеха на мировом рынке, и дал рекомендации 1С-стартаперам.

04.06.2018    11665    0    RayCon    21