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

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

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

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

Какие задачи можно решить с помощью UML? Несколько примеров из личного опыта.

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

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

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

Другой пример – автотранспортное подразделение крупной нефтегазовой компании. Мы там автоматизировали механизм планирования:

  • Расчет годовых планов;
  • Календарное планирование;
  • И уже непосредственно работу с заказ-нарядами в рамках тех лимитов, которые следуют из планов.

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

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

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

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

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

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

Возникающие вопросы

Когда я только начал заниматься моделированием бизнес-процессов, я столкнулся с гигантским океаном информации, и у меня возникло много вопросов:

  • Возможных нотаций описания очень много, но никаких сравнительных анализов по ним я на тот момент не нашел. Было непонятно, чем одна нотация лучше другой? Почему нужно использовать BPMN или IDEF, и как их использовать?
  • Какой должна быть модель? Чем больше я занимаюсь построением моделей, тем больше я понимаю, что не всегда нужно рисовать схему. Это может быть текстовое описание, или, возможно, это будет какая-то комбинация нотаций: не только UML, а UML плюс что-то. Не столь важно, что рисовать, важно понимать, модель какого объекта мы хотим представить, хотим понять.
  • Когда ко мне на собеседование приходят аналитики, мой любимый вопрос: «когда нужно готовить описание бизнес-процессов – до технического задания или после?» На это мне обычно отвечают, что должно быть две модели – «как есть» и «как должно быть», план перехода и прочие умные слова. Но по факту, на две модели в бюджете ресурсов никогда нет. И к тому же согласовать построение нескольких моделей очень трудно.
  • К тому же, когда я только начинал заниматься моделированием, особенность наших проектов была в том, что они проводились на базе типовых конфигураций, и мне не всегда было понятно, а какие процессы рисовать? Как строить модель так, чтобы не перерисовывать все готовые процессы типовой конфигурации, но при этом, чтобы это было эффективно и понятно пользователю?

На все эти вопросы я постараюсь в статье ответить.

Теоретические аспекты моделирования

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

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

При этом нотация может определять то, как мы строим модель, и также нотация может быть у конкретной диаграммы (диаграмма может иметь свои определенные правила составления).

Чтобы проще это понять, можно представить, что:

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

Какие проекции нам нужны?

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

И все моделирование нашего объекта (нашего предприятия с его информационной системой и его пользователями) проводится в рамках выбранной нотации.

Выбор нотации для моделирования

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

  • Если в модели состава бизнес-процессов мы определили, что у предприятия есть процессы:
    • Продажи,
    • Закупки,
    • Финансы
    • И управление,
  • Соответственно, на следующем уровне (в модели бизнес-процессов) у нас должно быть 4 диаграммы на каждый бизнес-процесс предприятия.

И уже после того, как мы определили:

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

Например, состав бизнес-процессов можно промоделировать, как минимум, в трех нотациях:

  • IDEF0;
  • UML:UseCase;
  • DFD;
  • и еще масса вариантов.

Какой выбрать – решать вам. А я постараюсь объяснить, почему UML удобнее всего.

IDEF0

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

Первым делом мы рассмотрим диаграмму, построенную в нотации IDEF0. Похожа на микросхему. Обратите внимание, здесь:

  • Квадратиками изображаются бизнес-процессы.
  • Стрелочки слева – это входящие потоки.
  • Стрелочки справа – исходящие потоки.

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

BPMN

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

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

DFD

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

ARIS <>EPC

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

Нотация EPC – очень неплохая, в ней получаются понятные бизнес-процессы. Единственное, что если бизнес-процесс чуть сложнее, чем «принял заказ» - «отгрузил товар», то он редко укладывается на A4. Я когда в этой нотации диаграммы делал, мне приходилось их как-то склеивать, складывать – получались большие бумаги.

UML

Давайте рассмотрим схему модели UML: Use Case. Что здесь изображено?

  • Здесь изображено два участника бизнес-процесса – поросенок и волк, которые являются животными.
  • Они участвуют в некоторых сценариях.
    • Например, поросенок участвует в сценарии «Строит дом». Что такое сценарий «Строит дом»? Это – съездить на рынок, купить материалов, спроектировать дом, построить его, протестировать на прочность и т.д. Фактически, это – бизнес-процесс.
    • Есть другой сценарий «Кушает», в котором участвует волк и поросенок. Для волка это, наверное, приятно, а для поросенка – не очень.

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

Вот так бы выглядела объектная модель UML сказки «Три поросенка». Обратите внимание, сколько информации несет одна только связь. Здесь мы видим, что один поросенок (это обозначает цифра «1» в начале связи) строит один дом. О том, что он «строит» дом, мы видим надпись на стрелке. Связь «один к одному». Каждый поросенок построил для себя один дом.

Язык UML – это унифицированный язык моделирования для разработки моделей на основе многих видов диаграмм, например:

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

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

  • Первый критерий – это то, что диаграммы должны быть наглядными и простыми. Их должны понимать все люди, и понимать на таком уровне, что ты принес пользователю диаграмму и не объясняешь ему, что означает та или иная фигура, а обсуждаешь с ним предметно, что на этой диаграмме изображено. Диаграммы действительно должны помогать нам коммуницировать с пользователями.
  • В нотации IDEF думать очень сложно. И рисовать, в общем-то, тоже непросто. Вы на бумаге диаграмму IDEF вряд ли сходу нарисуете. А диаграмму UML: Use case набросать на доске или на бумаге совсем не сложно, и это будет понятно.
  • Конечно, было бы удобно, чтобы все модели можно было построить в рамках одной программы, чтобы не переключаться между разными окнами.
  • А также, поскольку ни одна из этих нотаций явным образом не предназначена для 1С, нам так или иначе придется расширять ее нашими обозначениями. Поэтому хотелось бы, чтобы нотация гарантированно поддерживала расширение и инструменты, которые эту нотацию поддерживают, также были расширяемыми.

Применение UML на практическом примере

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

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

После его прочтения с UML можно было бы закончить, потому что ничего не понятно: как применить это к 1С – непонятно, какие пакеты в наших проектах возникают – тоже непонятно. Поэтому на определение мы внимания не обращаем, а смотрим, как это применяется на практике. Здесь и далее все диаграммы будут построены в программном продукте Enterprise Architect.

  • В левом окне мы видим Project Browser – браузер модели, где представлены все элементы модели.
  • А справадиаграмма. В частности, здесь это – диаграмма оргструктуры. Вполне понятно, что нарисовано. Если у нас какая-то сложная оргструктура – подчиненные узлы подразделений можно убирать внутрь пакетов, и диаграмма все равно будет небольшая – будет вмещаться на одном листе А4.

Диаграмма состава бизнес-процессов.

  • Посередине перечислены те бизнес-процессы, которые выполняются на предприятии.
  • Слева – внутренние участники бизнес-процессов (сотрудники предприятия).
  • Справа – внешние участники бизнес-процессов.

После того, как мы построили модель состава бизнес-процессов, мы переходим непосредственно к описанию каждого конкретного бизнес-процесса. Сложные бизнес-процессы удобно раскладывать сначала на макро-шаги, а потом уже делать детальное описание каждого шага. Обратите внимание, при построении модели в Project Browser мы также получаем очень удобную навигацию по модели: удобно переходить между бизнес-процессами и находить нужный шаг.

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

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

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

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

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

Немного о бизнес-правилах. Бизнес-правила – это просто скрипт некоторого действия, он не персонифицирован.

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

Модель ролей.

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

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

Мы с вами посмотрели, как можно построить орг. структуру, состав бизнес-процессов, сами бизнес-процессы, роли и  профили, и бизнес-правила. При этом и для бизнес-процессов, и для бизнес-правил мы использовали диаграммы UML:Activity. Но выглядели они по-разному, и это – нормально, UML допускает, что одинаковые диаграммы могут выглядеть по-разному, когда дополнены нужными нам элементами.

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

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

Но ни в коем случае не моделируйте всю конфигурацию, делайте модели только того, что вы меняете, чтобы новые люди, которые приходят, видели изменения типовой конфигурации. Модель типовой конфигурации ERP2 поставляется самой фирмой 1С на IDEF0, она входит в состав дистрибутива к ERP2. А нам важно понимать, что для типовой модели в рамках проекта нужно дополнить.

На слайде показана модель метаданных небольшой подсистемы «Управление предложениями».

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

Далее, после того, как мы построили модель метаданных, можно смоделировать алгоритм.

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

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

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

Как вы видите, с помощью UML мы построили полную нотацию для выполнения проекта на 1С. Причем используя только основные диаграммы, немного их модифицировав.

Требования и модели

Теперь несколько слов о требованиях.

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

Как между собой связаны требования и модель? Напрямую они не связаны. Модель показывает как будет выглядеть система, удовлетворяющая требованиям. И если посмотреть на расшифровку видов требований - то согласно ГОСТ34, там про модель ничего не сказано. Можем ли мы модель задокументировать в техническом задании? Если следовать ГОСТ - то, нет. Но если очень хочется, то можно.

Давайте разберем две ситуации.

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

Обращаемся к стандартам ГОСТ 34, по которому работают все крупные заказчики. Стандарт ГОСТ 34 предусматривает этап работ «Технический проект». Обратите внимание, «Технический проект» – это не документ, а этап работ. И в рамках этого этапа работ согласно ГОСТ34 есть документ, который подходит для документирования модели бизнес-процессов - "Описание автоматизируемых функций". А так как этап «Технический проект» – это вполне формализованный этап по  ГОСТ 34, то логично в его рамках модель системы задокументировать и утвердить у заказчика. С крупными заказчиками успешно проходит.

Другой вариант – когда заказчик вас нанимает и говорит: «Техническое задание будете делать вы, но никаких дополнительных документов я на проекте видеть не хочу, я хочу видеть только техническое задание». Лично сталкивался – мне была поставлена задача: «мне нужно техническое задание и все». Я выяснил аргументы того заказчика: опасения были в том, что пользователи привыкли к ТЗ и другие документы рассматривать и изучать не будут. Что в этом случае делать?

В этом случае можно поступить просто – вставить модель в техническое задание. Формально по ГОСТ34 так делать нельзя. Но когда очень хочется, то можно.

  • В техническом задании есть «Раздел 2. Характеристика объектов автоматизации». Тут можно разместить состав бизнес-процессов и орг. структура.
  • Также в техническом задании есть «Раздел 3. Требования к информационной системе». Вы их группируете по подсистемам, которые автоматизируете. И перед началом блока требований вставляете схему того бизнес-процесса, для которого эти требования были выработаны.

Мне никто ни разу не сказал, что у меня ТЗ не по ГОСТу. Всегда такой документ принимался. Пользователи видят эти схемы, им все понятно, и ТЗ становится понятнее.

Еще один вариант – это когда вы приходите к клиенту, и там не проект, а клиент просто хочет обработку. Например, изобрел какую-то уникальную схему заказа товаров, которую в УТ11 реализовать нельзя, и просит: «сделай мне ее этот отдельный блок».

В этом случае можно:

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

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

Не надо пытаться всегда продать полный этап обследования. Делайте частично, включайте эти модели в документы, которые вам все равно надо согласовывать. Это не очень нагрузит аналитиков и не очень увеличит время составления документов. Зато, в будущем существенно съэкономит время.

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

  • Сначала вы строите модель одного процесса (первый проект),
  • А потом на основании следующего проекта дополняете эту модель.

Получается, что процесс моделирования – непрерывный. Вы им постоянно занимаетесь и органично вписали его в свой процесс.

Представьте себе, как было бы здорово: приходите вы к клиенту, а он вам дает свою модель в каком-то виде (в виде файла или в виде доступа к системе проектирования, где у него описаны бизнес-процессы). И вместе с этим дает документ, который объясняет, как дорабатывать эту модель, и как эти доработки потом разложить по документам проекта. Утопия? Возможно. Но я думаю, мы к этому придем. Ведь так нам и нашим заказчикам будет проще, проект будет выполняться быстрее и качественнее, и мы лучше будем понимать заказчика.

Заключение

Перед тем, как строить модели, обратите внимание на особенности заказчика. Я лично сталкивался с людьми, которые не понимают схемы – они хотят вас слышать, им лучше принести ТЗ и рассказать его голосом. Это лучше выяснить до того, как вы начнете строить модели.

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

Тема моделирования очень важна для повышения эффективности наших проектов, но, к сожалениию, в нашей отрасли пока не очень популярна. Давайте обсуждать эту тему. Если у вас есть какие-то примеры проектов, которые вы хотите обсудить, напишите мне, я с удовольствием подключусь.

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

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

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

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

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. rusmil 218 04.09.17 06:18 Сейчас в теме
Очень хорошая статья, написано интересно, наглядно и доступно. Спасибо.
Deslime; D@y; user597616_i.d.kravchenko; SergeyN; +4 Ответить
2. Alex_grem 248 06.09.17 13:00 Сейчас в теме
Ещё бы файлик модели приложить...
3. immemor 08.09.17 11:45 Сейчас в теме
4. boln 1026 08.09.17 12:20 Сейчас в теме
Плюсанул, едва прочитав. Давно назревший разговор, независимо от того, насколько хороша статья.
5. Evgen.Ponomarenko 549 10.09.17 21:23 Сейчас в теме
Хорошая, правильная статья. Как раз принимаю участие в проекте по кодогенерации для целей IoT. Первые рабочие прототипы были написаны на 1С. Так, что генерация кода 1С средствами 1С - пройденный этап. Тем более, что тема моделирования мне очень близка см. https://infostart.ru/public/285811/ Надеюсь на продолжение беседы.
6. ifilll 15.09.17 16:24 Сейчас в теме
Кроме UML ничего не использовал, IDEF0 откровенно пугает, очень сложно воспринимается.
Спасибо, расширили кругозор.
7. boln 1026 13.11.17 16:59 Сейчас в теме
Вопрос автору.

Есть ли средство в UML компактно отобразить наследование от предопределенного абстрактного класса? Например, для документа "Приходная накладная" не громоздить стрелку наследования от абстрактного класса "Документ", а изобразить как-то попроще, что "Приходная накладная" есть "Документ"?
8. amaksimov 12.09.18 14:30 Сейчас в теме
(7) может в названии задействовать , типо Документ::Приходная накладная
9. boln 1026 12.09.18 15:08 Сейчас в теме
(8)
может в названии задействовать , типо Документ::Приходная накладная
Хорошая идея. Только тогда нужно прописывать в примечаниях к диаграмме, что это означает.
А стандартно-документированной нотации, как я понимаю, нет? Задавал этот же вопрос на UML-форумах, ответа не получил.

Только я бы предпочел использовать не C++, а Java-нотацию: ПриходнаяНакладная extends Документ :)
amaksimov; +1 Ответить
10. SergeyN 794 09.09.19 11:47 Сейчас в теме
(9) Еще вариант поместить в package: будет отображаться ПриходнаяНакладная (from Документы)
11. sytkosa 119 04.01.20 20:23 Сейчас в теме
(0) Автор вы можете в статье привести ссылки на программы в которых вы делали иллюстрации к статье. Из вашего опыта в какой программе лучше всего делать UML модель для 1С ?
12. SergeyN 794 17.04.20 13:35 Сейчас в теме
Оставьте свое сообщение

См. также

Ошибки управленцев: как топ-менеджеров убивает перфекционизм Промо

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

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    9924    user809424    11    

Как стать исполнителем в проекте от Инфостарта

Управление командой Управление проектом Бесплатно (free)

Инфостарт в поисках специалистов, которые готовы взяться за реализацию интересных проектов. Как подать заявку и стать исполнителем, с кем согласна сотрудничать компания и на каких условиях, рассказал руководитель проектов корпоративного отдела Инфостарта Александр Блинов.

11.09.2020    2630    alexandr.blinov    17    

Давайте спасем древесных осьминогов или 12 советов для начинающих РП от опытных товарищей

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

Ниже я попыталась собрать житейские советы от опытных руководителей проектов 1С и выпускников курсов по управлению ИТ-проектами на Инфостарте с моими комментариями. 

04.09.2020    2880    MariaTemchina    23    

Управление в стиле Догвилль

О жизни Управление проектом Бесплатно (free)

Как и почему жизнь на работе становится всё хуже. Или всё лучше.

26.06.2020    4335    1c-intelligence    17    

Проблемы внедрения 1С:ERP на крупном предприятии Промо

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

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом реальных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию очередную статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

29.06.2017    34529    1СERP    79    

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

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

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

19.06.2020    3106    SergeyN    0    

Есть ли жизнь после внедрения, или упрощаем работу в сопровождении

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

Из-за отсутствия грамотных правил разработки на этапе внедрения сильно усложняется работа по поддержке и развитию типовых доработанных конфигураций. О некоторых правилах и подходах в разработке, которые помогут специалистам сопровождать внедренное решение, на конференции Infostart Event 2019 Inception рассказал разработчик компании «Инвестиционная группа Абсолют» Алексей Степаненко.

08.06.2020    4878    stepan96    12    

Добрый великан

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

Руководители проектов определяют наше настоящее, каким оно будет?! Ответ прост - таким, каким и сам РП.

25.05.2020    5429    sapervodichka    1    

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

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

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

28.06.2017    30900    raiml    37    

Почему Scrum не работает в проектах 1С

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

Более точная формулировка заголовка, пожалуй будет такой -  Почему Scrum в чистом виде плохо работает в проектах внедрения продуктов 1С.

18.05.2020    10849    MariaTemchina    33    

Кто здесь? Или как проводить онлайн-совещания

Управление проектом Управление командой Бесплатно (free)

На самом деле, переход рабочей жизни в онлайн обладает некоторым количеством плюсов. В частности хочется верить, что формальный контроль “отслеживаем кто сколько часов проработал, проверка, что сотрудники на месте и все чем-то заняты” заменится фактической отчетностью “по результатам”.

23.03.2020    5741    MariaTemchina    24    

4 причины, почему проекты никогда не завершаются в срок

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

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

03.03.2020    6255    VLikhobabin    44    

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

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

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

28.06.2017    30307    raiml    10    

7-ой PMBoK - конец классического проектного управления? Часть 1-ая

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

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

23.01.2020    15492    MariaTemchina    8    

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

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

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

09.01.2020    7012    roman72    0    

Незакрытый проект на 1000 часов

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

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    12371    ogroup    163    

История одного неуспешного проекта Промо

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

В ходе публикации предыдущих статей о проектной технологии ВЦ «Раздолье» и системе мотивации в фирме-франчайзи 1С, читатели попросили поделиться опытом неуспешных проектов, поскольку парадные рапорты о нескончаемых успехах всех утомили и не несут пользы для профессионалов. Мы попросили руководителей проектов ВЦ «Раздолье» поделиться такой непростой информацией. И сейчас представляем Вашему вниманию первую статью по этой теме. Автор – Пикурен Вера – руководитель проектов ВЦ «Раздолье».

09.06.2017    31194    1СERP    175    

Стратегия выживания в корпоративных войнах

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

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

16.09.2019    9819    GSoft    16    

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

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

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

30.08.2019    12354    SergeyN    8    

Эволюция пользовательской документации 1С в производственной компании

Пользователю системы Управление проектом Бесплатно (free)

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

20.08.2019    8946    Arsen1986    7    

Такие разные франчайзи. Часть вторая: Особенности реализации крупных проектов, Глава 1. О людях Промо

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

Продолжаем публикацию цикла статей о бизнесе франчайзи 1С. В предыдущих статьях мы рассказали о наиболее распространенном мнении о фирмах франчайзи 1С, об истории развития франчайзинга. Поставили вопрос о выборе системы мотивации. Предыдущие публикации вызвали оживленное обсуждение. В продолжении темы расскажем о том – как выглядит работа проектного подразделения фирмы-франчайзи. Расскажем на примере проектного офиса ВЦ «Раздолье». Предложим обсудить проблемы, с которыми приходится сталкиваться в проектном бизнесе. Автор статьи Андрей Мироненко.

18.04.2017    32160    1СERP    189    

Управление проектами по автоматизации бюджетирования

Управление проектом Финансовый учет и бюджетирование (FRP) Финансовый учет и бюджетирование (FRP) УУ Бесплатно (free)

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    8178    SergeyN    1    

Цифровая трансформация. Будущее учетных систем

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

О цифровой трансформации слышали все, но немногие в этом разбираются. Что она собой представляет, какие несет изменения, на что надо обратить внимание айтишникам и 1С-никам, рассказал на конференции руководитель департамента автоматизации строительных организаций компании «Первый БИТ» Иван Аверьянов.

19.06.2019    10312    FB_10160810658600104    62    

Риск - благородное дело!.. Часть первая

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

Несколько рекомендаций по управлению рисками в ИТ-проектах.

18.06.2019    7643    MariaTemchina    8    

Такие разные франчайзи, или как мы делаем большие проекты на 1С. Часть первая: ты помнишь, как всё начиналось Промо

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

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

10.04.2017    32107    1СERP    107    

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

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

В своей публикации “Устав писать Устав” я много рассуждала о том, как полезно умение договариваться на берегу. Как известно, у каждого человека в голове своя картина мира. В целом, многие конфликты в ходе проектов происходят как раз из-за конфликта ожиданий, и из-за нечетких договоренностей, кто чем должен заниматься.  

31.05.2019    9267    MariaTemchina    23    

Как мы со Стасом завод за 2 месяца автоматизировали

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

Мой опыт быстрого внедрения.

14.05.2019    11282    1c-intelligence    121    

Устав писать Устав

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

Ответы на вопросы про то, нужен ли Устав для проектов автоматизации, и если нужен, то зачем?

06.05.2019    7680    MariaTemchina    8    

Мотивация персонала в фирмах франчайзи: а она работает? Промо

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

Думаем, что практически любого работающего человека интересует вопрос мотивации. Этой проблемой в одинаковой степени озабочены работники и работодатели: как мотивировать людей, сколько платить, как платить, какая часть оплаты должна быть фиксированной, а какая зависеть от результата работы, как это всё повлияет на результаты работы, стоит ли быть строгим и дотошным руководителем или нужно активно делегировать полномочия подчиненным. ВЦ "Раздолье" провело небольшое исследование на тему мотивации и вот его результат. Автор статьи Андрей Мироненко.

03.04.2017    42952    1СERP    231    

Путь джедая в управлении проектами 1С: умение быть, а не казаться

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

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    11874    MariaTemchina    15    

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

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

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

07.03.2019    11282    1c-intelligence    49    

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?"

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

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    8276    chavalah    22    

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

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

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

23.02.2017    27709    Gavrik    10    

Бизнес, не горюй

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

Про цели автоматизации.

04.02.2019    10151    1c-intelligence    64    

Что немцу хорошо, то русскому... Как минимум, небезынтересно. Продолжаем тему Канбан

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

Пользуясь несовпадением рождественских каникул в России и Германии, решила познакомиться с тем, как организована работа разработчиков в одном немецком банке. Сразу оговорюсь: еще давно, со времен совместных яхтенных плаваний с немцами, я противник четких стереотипов из серии "все русские всегда...." или "все немцы обязательно..." (пропущенные места предлагаю читателям заполнить самим в меру своей испорченности).

14.01.2019    10220    MariaTemchina    13    

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях"

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

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    12984    chavalah    123    

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

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

Не так давно на одном из проектов во время инвентаризации была выявлена очень большая недостача. Как результат, одно из важнейших требований клиента по проекту было: разобраться с тем, что у него происходит в системе, и привести остатки, как он выразился, «в адекватное состояние». А незадолго до этого у меня в практике был случай, когда уже на второй день после внедрения качественной системы учета движения наличных денежных средств (кассы) также была выявлена недостача, но уже в кассе. И в первом, и во втором случае вину за возникновение проблемы представители заказчика попытались возложить на людей, которые занимались внедрением новой системы. И только после долгих и, надо признаться, довольно неприятных и очень эмоциональных разбирательств, удалось доказать клиенту, что система работает правильно, а виноваты в случившемся сотрудники компании, которые намеренно или ненамеренно создали фактическую недостачу товара и денег.

17.06.2016    40287    raiml    37    

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

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

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

26.12.2018    9946    1c-intelligence    7    

Озарение после прочтения макулатуры по проектному управлению

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

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    9923    MariaTemchina    24    

20 мыслей об ИТ-проектах, или 20 лет спустя.

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

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    9259    chavalah    119    

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

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

Мне, как одинэснику, не приходилось заниматься какими-то узкими задачами «от сих до сих». Вся моя профессиональная деятельность, как одинэсника, была всегда связана с очень широким кругом вопросов. Наверное, потому, что я работал, в основном, в малых компаниях, где приходилось работать над всем спектром вопросов.

26.12.2014    44804    CheBurator    64    

Памятка руководителя: не играйте с деньгами

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

Важная статья о персонале из цикла «Памятка руководителя»: здесь я планирую затронуть один из наиболее острых вопросов – деньги. А также развернуто ответить на некоторые комментарий читателей по двум прошлым статьям.

05.12.2018    17182    andironenko    128    

Шаг назад и ... шаг назад (классификация внутренних проектов)

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

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

03.12.2018    8779    capitan    26    

Белая и пушистая рецензия на Чёрную книгу Скрам

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

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

26.11.2018    10266    MariaTemchina    40    

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

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

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

26.03.2015    31774    CheBurator    33    

Памятка руководителя: Будьте оптимистичным или на крайний случай злым

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

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    12682    andironenko    43    

Создание концепции проекта (project scope statement). Курс по управлению проектами, часть 8

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

Что такое концепция проекта? Это понятие, близкое по смыслу к техническому заданию (ТЗ). Одно из определений концепции - детальное, целостное описание работ в удобной для команды форме.

19.11.2018    8464    Selikhovkin    2    

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия)

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

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

19.11.2018    9474    capitan    41    

Практика пуска склада продуктов питания Промо

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

Описывается опыт пуска склада (охлажденная и замороженная продукция) с точки зрения IT. Со временем из складского подразделения была создана компания, которая оказывает логистические услуги (3PL-оператор) сторонним Клиентам.

1 стартмани

14.09.2015    36341    axxell    15    

Почему внедрение ERP-системы не приносит пользы бизнесу?

Интеграция Управление проектом Бесплатно (free)

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

15.11.2018    25144    rossoxa    66    

Думать некогда, трясти надо - или что такое ретроспектива в Agile

Управление проектом Agile (XP, SCRUM, Канбан) Бесплатно (free)

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике. 

13.11.2018    10315    MariaTemchina    16    

Памятка руководителя: В одиночку здесь не выжить

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

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

07.11.2018    12409    andironenko    62