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

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

Управленческий учет - С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 в Москве.

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

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

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

См. также

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

Анализ и проектирование ИТ-систем Бесплатно (free)

Часто сталкиваюсь с непониманием того, кто такой архитектор. Во многих командах эту компетенцию не используют, либо используют неверно. В связи с непониманием того, как устроен процесс разработки в сфере 1С и кто за что отвечает, будут написаны 8 статей. Это первая статья. В статье постараюсь раскрыть роль архитектора и его значимость в процессе проектирования и разработки. Основываюсь на своём опыте (более 15 лет). Для написания этой статьи изучал статьи на эту тему от коллег и консультировался с руководителями крупных команд.

30.06.2020    20571    biimmap    72    

Как быстро нарисовать блок-схему или изобразить бизнес-процесс

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

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

25.11.2021    938    VachKirp    5    

Модель C4 (C4 model) для визуализации архитектуры программного обеспечения

Анализ и проектирование ИТ-систем Бесплатно (free)

Перевод главной страницы сайта https://c4model.com/, посвященной C4 model.

26.10.2021    602    malikov_pro    9    

Использование PlantUML в Redmine

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

В статье опишу порядок настройки плагина PlantUML для Redmine 4.2

25.10.2021    334    malikov_pro    2    

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

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

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

24.04.2019    29941    siddy    0    

Детские механизмы для взрослых людей

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

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

06.09.2021    1156    ashtey    6    

Берримор, ты потерял рецепт овсянки? Не беда, нам поможет DFD!

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

Методология DFD наряду с нотациями IDEF0 и IDEF3 входит в тройку популярных методологий описания бизнес-процессов. Мы не говорим о современных нотациях eEPC или BPMN, мы говорим о классике.

16.08.2021    1396    ashtey    2    

Мухи отдельно, котлеты отдельно. Или когда использовать IDEF3?

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

С нотацией IDEF0 разобрались, теперь поговорим о следующем представителе семейства IDEF – нотации IDEF3.

08.08.2021    2077    ashtey    6    

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

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

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

05.09.2017    43628    alexrovich_ru    56    

Почему мы не любим заказчиков (не умеем их готовить)

СRM Методология Бесплатно (free)

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

05.07.2021    1476    user1429991    0    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 4

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Сколько бизнес-аналитиков – столько и мнений: какая нотация лучше и какую следует использовать при моделировании бизнес-процессов. Рассмотрим следующую группу нотаций…

01.06.2021    2964    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 3

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Итак, сейчас рассмотрим уже самые разнообразные графические нотации и начнем с очень неожиданной – ДРАКОНа.

03.05.2021    3013    ashtey    13    

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

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

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

28.06.2017    45315    raiml    37    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 2

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Самая суть – графическая нотация моделирования бизнес-процессов. Какие бывают и когда их использовать… Начнем с семейства нотаций IDEF.

22.04.2021    6225    ashtey    1    

Краткий путеводитель по методологиям и нотациям описания и моделирования бизнес-процессов. Часть 1

Анализ и проектирование ИТ-систем УУ Бесплатно (free)

Их действительно много – разных нотаций и методологий моделирования бизнес-процессов. Как понять, какую выбрать?

19.04.2021    14457    ashtey    6    

Котлеты по-одесски, или с чем кушать IDEF0

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

В статье я расскажу, как же приготовить котлеты с помощью нотации IDEF0.

23.03.2021    2430    ashtey    5    

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

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

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

28.06.2017    35338    raiml    10    

Пишем ТЗ через сценарии

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

От того, насколько одинаково понимают ТЗ заказчик и исполнитель, зависит успех проекта. Включение моделей на UML и BPMN в состав ТЗ помогает упростить взаимопонимание с заказчиком и обеспечить минимум доработок за счет полного покрытия всех процессов функциональностью системы. О том, как грамотно составить ТЗ и увязать требования заказчика с детализированными моделями, на митапе Saint Petersburg.Online рассказал Сергей Наумов.

05.03.2021    4579    SergeyN    6    

Как получить из текста в BPMN схему. Видеоинструкция

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

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

16.02.2021    1275    raiml    3    

Практика применения DevOps. Тестирование

DevOps Сценарное тестирование BDD/TDD-тестирование, Vanessa СППР v8 1cv8.cf Бесплатно (free)

В третьей части мастер-класса «Практика применения DevOps» на конференции Infostart Event 2019 Inception выступила Светлана Попова. Она рассмотрела возможности использования двух инструментов тестирования от фирмы «1С» – «Сценарного тестирования» и связки СППР и Vanessa Automation, и рассказала про плюсы и минусы каждого из этих вариантов.

11.12.2020    5594    SvVik    0    

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

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

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

23.02.2017    28687    Gavrik    11    

Средства для анализа бизнес-процессов. Есть ли лучшее?

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

Как правильно выбрать средство для описания и анализа бизнес-процессов? Какие функции требуются от «идеального» продукта и чем сейчас пользуются участники 1С-сообщества в своей работе? На meetup для бизнес-аналитиков, который прошел 13 ноября 2020 года в рамках моего доклада, я провела небольшой опрос на эту тему. И сегодня хочу поделиться результатами анализа ваших ответов, а также теми наблюдениями, которые я в последнее время делаю, изучая рынок специализированных BPM средств.

20.11.2020    13418    e_ivanova    0    

И снова про бизнес-процессы: живой опыт без теории

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

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

20.10.2020    2568    e_ivanova    6    

Чего хочет разработчик от ТЗ? Примеры из практики

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

Модная нынче тема - составление ТЗ и формирование технических требований. Внесу свою маленькую лепту в виде примеров из личной практики и того, каким я вижу идеальное описание задачи. Задачи, которую можно просто взять и сделать! Без лишних вопросов.

16.10.2020    7627    stas_ganiev    36    

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

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

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

11.08.2016    36842    SamBadi    55    

Архитектор – строит, а что делает аналитик?

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

Как только вспоминаешь проект по внедрению, особенно тот, что средний и выше (а в уме мы держим, что это проект 1С), то тут же видишь кучу народа, и каждый что-то делает. И вот тут вопрос – кто и что делает на проекте?

14.10.2020    5128    ashtey    11    

Из хаоса в логику бизнес-процессов

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

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

06.10.2020    13296    ashtey    5    

CRM-система в 1С для автоматизации отдела продаж. Почему 1С – это лучшая платформа для CRM-системы? 

СRM УУ Бесплатно (free)

Кто-то с CRM-системами только знакомится, а кто-то уже активно пользуется. Какие инструменты в ней должны быть, чтобы с ее помощью выстроить эффективную работу отдела продаж, на конференции Infostart Event 2019 Inception рассказал директор по развитию компании Alexrovich Андрей Киселев.

28.09.2020    13891    andre1kiselev    5    

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

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

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

26.03.2015    32406    CheBurator    36    

Что делать, если с поддержкой 1С всё горит или несколько слов про ITSM…

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

Проекты - это, конечно, важно, с завершением проекта внедрения, жизнь прикладного решения, на самом деле, только начинается. И самое интересное еще только впереди… Не случайно в Agile все чаще говорят о “гибком управлении продуктом”, а вовсе не только “проектом”.

20.08.2020    3666    MariaTemchina    4    

Модуль логиста: как обычная доработка стала тиражным решением

СRM Монитор заказов Розничная торговля Управление услугами и сервисом v8::ОУ 1cv8.cf УУ Бесплатно (free)

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

18.08.2020    3318    RAU IT    2    

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

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

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

30.06.2020    2322    biimmap    5    

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

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

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

06.04.2015    38567    raiml    14    

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

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

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

28.05.2020    11039    sapervodichka    75    

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

СППР Методология Бесплатно (free)

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

09.01.2020    13498    roman72    0    

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

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

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

06.01.2020    4591    roman72    9    

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

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

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

20.11.2019    41303    YPermitin    19    

Vanessa Automation + СППР

BDD/TDD-тестирование, Vanessa СППР v8 Бесплатно (free)

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

07.11.2019    16255    SvVik    15    

Модернизация КА 2.4 под маркетинговую компанию. Часть 1

СRM Техническое задание v8 КА2 Россия УУ Бесплатно (free)

Выполнил для компании, которая занимается маркетингом и продвижением продуктов, проектирование и модификацию конфигурации КА 2.4 и справочника «Проекты». Теперь в конфигурации «Проекты» имеют особенную роль и на основании выполненной доработки руководство компании принимает решения по продолжению, закрытию или продвижению проекта/ов, поиск путей решения возникающих вопросов. При необходимости доработку можно реализовать под ERP конфигурацию. Архитектура решения выполнена «рядом» с основной конфигурацией. В настоящее время конфигурация поддерживается, модификация ведется в актуальной версии КА 2.4.10 на платформе 8.3.14.1630.

29.10.2019    6778    BraunAlex    1    

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

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

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

27.02.2015    27948    izidavld    69    

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

СRM Мотивация, лидерство и личная эффективность Бесплатно (free)

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

11.10.2019    4684    Шёпот теней    4    

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

Методология СППР Бесплатно (free)

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

30.08.2019    16475    SergeyN    10    

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

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

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

26.07.2019    5449    user1063453    0    

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

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

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

09.12.2013    22930    pro-rok    15    

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

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

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

26.07.2019    7463    slozhenikin_com    14    

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

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

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

09.06.2019    5103    Arsen1986    6    

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

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

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

30.05.2019    11907    rpgshnik    16    

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

Техническое задание Анализ и проектирование ИТ-систем Россия Бесплатно (free)

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

29.06.2005    37409    support    11    

Организующая схема — карта вашего бизнеса. Как использовать для автоматизации

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

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

07.05.2019    9029    siddy    0    

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

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

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

07.03.2019    12133    1c-intelligence    50