Comments 36
Если это всё счастье рисовалось Вашим приложением, то следует признать, что презентация её возможностей Вам явно удалась! :)
Что же, чудесно, спасибо за комплимент! Но, такой результат не полностью заслуга приложения, диаграммы составлены так чтобы легко и чисто читаться — вот этим опытом я и хочу поделиться.
UFO just landed and posted this here
Отчего же, приложение и web-сервис разработаны мною, у меня в профиле есть ссылки на сайты wokflow.link и inShort.
«Существует много нотаций описания диаграмм процессов, это IDEF0...»
Увы, не нашёл, что бы можно было сделать по инструкции после прочтения этой фразы.
Увы, не нашёл, что бы можно было сделать по инструкции после прочтения этой фразы.
UFO just landed and posted this here
Да, формально вы правы IDEF0 — для функционального моделирования. Однако на практике функциональная модель по структуре может практически совпадать с моделью процессов и наоборот, отчего часто модель процессов верхнего уровня просто заменяют функциональной моделью. Можно считать это некорректным, но вполне практичным решением.
Тема статьи интересная, но очень не хватает иллюстраций для демонстрации примеров.
Круто, спасибо за статью.
Главное чтобы не уйти в художники после этого навыка.
Главное чтобы не уйти в художники после этого навыка.
Спасибо! Отличная статья.
Споткнулся только на Шаге 5. Почему просто не добавить ресурс, который забыл указать на Шаге 2? Вероятно, тут не про вариант «если вы забыли», а про… что?
Споткнулся только на Шаге 5. Почему просто не добавить ресурс, который забыл указать на Шаге 2? Вероятно, тут не про вариант «если вы забыли», а про… что?
На Шаге 2 определяются исходные ресурсы, то есть те которые должны быть в наличии перед началом исполнения работ, это довольно узкий список. А на Шаге 3 определены ресурсы, которые так или иначе становятся доступны в процессе работ, в принципе они могут включать в себя и исходные ресурсы и те ресурсы, которые были произведены по ходу дела. Ресурсы Шага 3 представляют собою более общее множество поэтому переход и ведёт к этому шагу.
Статья без диаграмм про диаграммы.
В конце статьи её содержание приведено в виде диаграммы. Примеры я не стал приводить сознательно, так как они побуждают действовать по шаблону, а на данном этапе куда важнее “схватить” общий принцип изложенного метода.
Хотя, вот сейчас подумал, что можно было бы привести несколько негативных примеров, как не нужно делать, они точно не стали бы шаблоном, но иллюстрацию дали бы.
Хотя, вот сейчас подумал, что можно было бы привести несколько негативных примеров, как не нужно делать, они точно не стали бы шаблоном, но иллюстрацию дали бы.
Shortki, традиционный вопрос: диаграммы руками рисовали?
Всё в так или иначе делается руками, но нет, диаграммы не были “нарисованы”, они были построены руками из готовых блоков в специальном приложении, после чего можно задать временные параметры созданного процесса, провести симуляцию исполнения, назначить исполнителей, сформировать план исполнения, получить диаграмму Гантта, отслеживать прогресс и делать много другое.
Если вопрос о другом, то нет, диаграмма не была построена автоматически из формализованного описания.
Если вопрос о другом, то нет, диаграмма не была построена автоматически из формализованного описания.
Спасибо! Интересная и полезная статья. Сайт wokflow.link с удовольствием просмотрел, классно сделано.
Есть способ строить диаграммы — ДРАКОН. Его использовали при построении Бурана, в этом проекте участвовало 2 миллиона человек.
Вашу диаграмму можно улучшить с помощью этой концепции.
Рекомендую книгу на эту тему «Как улучшить работу ума» — В.Д.Паронджанов.
Вашу диаграмму можно улучшить с помощью этой концепции.
Рекомендую книгу на эту тему «Как улучшить работу ума» — В.Д.Паронджанов.
Честно попробовал пользоваться сервисом, но невозможность делать папки или блоки одинакового размера превращает все в цирк. Добавьте, пожалуйста, или направляющие, или возможность указать точный размер, иначе это просто ад перфекциониста.
А то что лист начинается не с целой ячейки, а с половины, вообще убивает :)
При попытке создать папку хотя бы напоминающую папку «Руководство пользователя» поймал нервный тик, ибо папки не выравниваются по клеткам, размеры сжимаются автоматически по непонятной логике, практически ад. Сервис выглядит очень полезным, но лично для меня им пользоваться невозможно.
Спасибо, что поделились опытом пользования. Все размеры автоматически выравниваются по сетке, странно что у вас не так, а то что лист начинается не с целой ячейки, а с половины, вообще не понятно — у себя я такого не отыскал. Можно поинтересоваться какой у вас браузер и ОС? При правке контента в браузере, есть некоторые неудобство по сравнению с десктоп-приложением, но чтобы “нервный тик” не сталкивался, но я не в терминальной стадии префекциониста, хотя временами предаюсь этому пороку.
Последний Chrome, Windows 10.
Скрин стартового листа с половиной ячейки:
i.imgur.com/G68xf0i.png
Моя лучшая попытка сделать одинаковую папку (потратил около 3-х минут и все равно видно, что одна папка выше):
i.imgur.com/zVIOm1i.png
Я для работы использую Mindjet, и там вообще нет сетки, но при этом есть возможность скопировать стиль. Какие варианты я вижу у вас, чтобы все выглядело более-менее структурированно:
а) указать размер элемента в клетках по ширине/высоте — отсутствует
б) указать размер элемента в пикселях — отсутствует
в) сделать копию стиля папки без копирования входящих элементов — отсутствует
г) возможность сдвигать элементы кнопками мышки на мини-клетку вверх вниз, чтобы выровнять точнее — отсутствует
д) подгонка размера элемента под клетки — присутствует, но неточная (как в моем примере, разница в 2-3 пикселя не критична, но лично мне портит все впечатление).
То есть я искренне пытался заставить себя пользоваться инструментом, но получается абсолютно кривая разноразмерная каша (именно у меня, инструмент прекрасный).
Скрин стартового листа с половиной ячейки:
i.imgur.com/G68xf0i.png
Моя лучшая попытка сделать одинаковую папку (потратил около 3-х минут и все равно видно, что одна папка выше):
i.imgur.com/zVIOm1i.png
Я для работы использую Mindjet, и там вообще нет сетки, но при этом есть возможность скопировать стиль. Какие варианты я вижу у вас, чтобы все выглядело более-менее структурированно:
а) указать размер элемента в клетках по ширине/высоте — отсутствует
б) указать размер элемента в пикселях — отсутствует
в) сделать копию стиля папки без копирования входящих элементов — отсутствует
г) возможность сдвигать элементы кнопками мышки на мини-клетку вверх вниз, чтобы выровнять точнее — отсутствует
д) подгонка размера элемента под клетки — присутствует, но неточная (как в моем примере, разница в 2-3 пикселя не критична, но лично мне портит все впечатление).
То есть я искренне пытался заставить себя пользоваться инструментом, но получается абсолютно кривая разноразмерная каша (именно у меня, инструмент прекрасный).
Ред.: не «кнопками мышки», а «стрелками клавиатуры».
На первом скрине не «половина ячейки» просто часть поля съедается линией отделяющей заголовок, хотя сама линия своим центром (но не краем) выровнена точно по третьей сверху клетке. Вообще объекты выровнены по сетке, но учитывая что ширина штрихов у них может варьироваться, то это может стать причиной наблюдаемого вами эффекта. Но не с папкой «Руководство пользователя» :) она создаётся особым образом и немного не подчиняется правилам, это особый случай, посмотрю что с этим можно сделать. Попробуйте повторить ваш эксперимент с двумя не системными папками.
а-б) Вполне возможно сделать, подумаю.
в) Объекты можно копировать, а свойств стилей не так много чтобы городить вокруг этого функционал, а ведь это новая кнопка в уже и так довольно сложном интерфейсе, который хотелось бы оставлять насколько возможно простым.
г) Там конфликт со скроллингом, не ясно как лучше, в общем пока оставили так.
а-б) Вполне возможно сделать, подумаю.
в) Объекты можно копировать, а свойств стилей не так много чтобы городить вокруг этого функционал, а ведь это новая кнопка в уже и так довольно сложном интерфейсе, который хотелось бы оставлять насколько возможно простым.
г) Там конфликт со скроллингом, не ясно как лучше, в общем пока оставили так.
В первую очередь, я хочу сказать, что описанное мной не я является прям такими уж важными комментариями, это скорее «я так вижу», и реагирую исходя из этого «видения» :)
1. По поводу «часть поля съедается» — но я-то этого не вижу, я вижу лист, который начинается с части ячейки (возможно, меньшей).
2. Если все остальные папки кроме «Руководство пользователя» действительно получаются одинаковыми, то проблема менее критична, но это, конечно, совсем не очевидно :)
Пунктов а-б было бы более чем достаточно, все остальное привел как примеры реализации в других продуктах :)
1. По поводу «часть поля съедается» — но я-то этого не вижу, я вижу лист, который начинается с части ячейки (возможно, меньшей).
2. Если все остальные папки кроме «Руководство пользователя» действительно получаются одинаковыми, то проблема менее критична, но это, конечно, совсем не очевидно :)
Пунктов а-б было бы более чем достаточно, все остальное привел как примеры реализации в других продуктах :)
1. Полностью согласна, что диаграмма должна быть адаптирована под аудиторию.
Но, на мой взгляд, нужно не только определить аудиторию, но и оставить об этом информацию будущим пользователям диаграммы (на самой диаграмме, в сопроводительной документации).
2. Пожалуй, соглашусь с предложенной последовательностью построения (конечные цели — доступные ресурсы — промежуточные цели — процессы) для схем to be.
Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: пользователи часто охотнее рассказывают о своей деятельности (то бишь о процессах), а вот цель этой деятельности не всегда могут сформулировать.
И одна из задач as is — определить процессы с неясными целями и, либо поставить им в соответствие какую-то полезную цель, либо «официально убить» эти процессы. Для as is, предложенная в статье последовательность будет способствовать «потере» процессов c неясными целями на схеме, но в реальной жизни они по прежнему будут исполняться.
Но, на мой взгляд, нужно не только определить аудиторию, но и оставить об этом информацию будущим пользователям диаграммы (на самой диаграмме, в сопроводительной документации).
2. Пожалуй, соглашусь с предложенной последовательностью построения (конечные цели — доступные ресурсы — промежуточные цели — процессы) для схем to be.
Для схем as is, думаю, нужно начинать с процессов, а уж к ним пристегивать цели и ресурсы: пользователи часто охотнее рассказывают о своей деятельности (то бишь о процессах), а вот цель этой деятельности не всегда могут сформулировать.
И одна из задач as is — определить процессы с неясными целями и, либо поставить им в соответствие какую-то полезную цель, либо «официально убить» эти процессы. Для as is, предложенная в статье последовательность будет способствовать «потере» процессов c неясными целями на схеме, но в реальной жизни они по прежнему будут исполняться.
1. Естественно это так и должно быть, любая диаграмма не существует сама по себе, он всегда находится в каком-то контексте с уже сформировавшейся аудиторией.
2. Чувствуется опыт. С моей экстремальной точки зрения в развитой корпоративной культуре as is не должно существовать, но в жизни всё иначе. Если to be это работа строителя, то as is это призвание реставратора в хорошем смысле, и патологоанатома в плохом. Это совсем разные подходы, и если для построения процесса еще можно предложить какой-то метод, то с анализом на месте всё сложнее, здесь работа больше похожа на занятие детектива.
Вспомнил байку, внешний консультант на предприятии никак не мог понять путь принятия решений — всё непрозрачно, куча комитетов, совещательных органов, согласований, но предприятие работает как часы. И вот заходит он в один небольшой отдел на отшибе где работали всего три девушки, как работали — бумажки перекладывали, в общем так и не понял он чем они заняты, но уходя заметил у одной пятна на руке от чернил двух цветов, а такие встречались на предприятии только в одном месте. Вот он и спрашивает: “А у вас есть Большая Круглая Печать?” А она: “Да, вот, а что такое?” Вот так вскрылся альтернативный оперативный путь принятия решений почти без согласований и болтовни. По пятнам! Такое ни в одной методике не предусмотреть.
Спасибо за комментарий.
2. Чувствуется опыт. С моей экстремальной точки зрения в развитой корпоративной культуре as is не должно существовать, но в жизни всё иначе. Если to be это работа строителя, то as is это призвание реставратора в хорошем смысле, и патологоанатома в плохом. Это совсем разные подходы, и если для построения процесса еще можно предложить какой-то метод, то с анализом на месте всё сложнее, здесь работа больше похожа на занятие детектива.
Вспомнил байку, внешний консультант на предприятии никак не мог понять путь принятия решений — всё непрозрачно, куча комитетов, совещательных органов, согласований, но предприятие работает как часы. И вот заходит он в один небольшой отдел на отшибе где работали всего три девушки, как работали — бумажки перекладывали, в общем так и не понял он чем они заняты, но уходя заметил у одной пятна на руке от чернил двух цветов, а такие встречались на предприятии только в одном месте. Вот он и спрашивает: “А у вас есть Большая Круглая Печать?” А она: “Да, вот, а что такое?” Вот так вскрылся альтернативный оперативный путь принятия решений почти без согласований и болтовни. По пятнам! Такое ни в одной методике не предусмотреть.
Спасибо за комментарий.
Чувствуется опыт.Есть немного.
В моей идеальной картине мира as is должны получаться из to be сразу после внедрения с отражением всех расхождений, которые образовались в процессе реализации. + должна постоянно поддерживаться актуальность этих схем. Я работаю на стороне клиента и мне, в отличии от внешних консультантов, важно иметь актуальную информацию по процессам: что бы быстро находить нужную инфу, что бы знания не лежали в чьей-то конкретной голове, а были доступны всей команде, для того, что бы разговаривать с пользователями на одном языке и т.д.
Но в жизни, конечно, все не так. Безусловно, крайне не хочется тратить время на as is до внедрения новых оптимальных процессов, но в некоторых случаях, на мой взгляд, это оправдано. Например, в следующих:
а) пользователи крайне неохотно делятся инфой о своих процессах (возможно из-за страха потерять свое насиженное место, уникальность-незаменимость или просто от природного косноязычия, не суть). В таких случаях мне важно отрисовать схемы и получить от пользователей подпись под ними. Что бы потом не было обвинений, что мы что-то не так поняли, упустили, не учли.
б) для иллюстрации каких-либо наших предложений по оптимизации, требующих волевого решения сверху: положительное решение более вероятно, если руководитель сравнивает as is и to be, чем когда просто лицезреет to be.
в) очень часто делаю выборочно схемы просто для себя — они могут понадобиться мне/коллегам позже в случае, если их трансформация под to be отложилась или отменилась.
У внешних консультантов таких необходимостей как правило не возникает, они пришли и ушли, а мне дальше с этим работать. Так что для меня as is — эта работа терапевта или даже этакого врача общей практики.
И да, запутанные процессы иногда распутываются на интуиции и мелких зацепках.
Похоже вы на секунду подумали, что я недооцениваю важность работы as is :), уверяю это не так. Я искренне желаю чтобы у медиков или пожарных не было работы, но это не значит что я плохо отношусь к их деятельности. Иногда проще профилактически внедрить что-то как должно быть, до того как понадобится диагностировать «что у нас там» и «лечить/тушить» это.
И да, актуальность это бич. Здесь помогает подход при котором исполнителям разрешено править конкретный процесс по мере его исполнения, и не относиться к процессам как к «золотому шаблону» — все случаи бывают разные, лучше зафиксировать как получилось, чем не знать что там было. Когда проявляешь гибкость, иногда прикрывая исполнителей в сложных ситуациях и «косяках», то сотрудники перестают «шифроваться», чаще приходят за советом «как лучше здесь поступить». Кстати, на стороне клиента я тоже долго проработал.
И да, актуальность это бич. Здесь помогает подход при котором исполнителям разрешено править конкретный процесс по мере его исполнения, и не относиться к процессам как к «золотому шаблону» — все случаи бывают разные, лучше зафиксировать как получилось, чем не знать что там было. Когда проявляешь гибкость, иногда прикрывая исполнителей в сложных ситуациях и «косяках», то сотрудники перестают «шифроваться», чаще приходят за советом «как лучше здесь поступить». Кстати, на стороне клиента я тоже долго проработал.
Спасибо, за статью!
Описанные тут рекомендации, подходят для построения большинства канонических диаграмм и изложены они аргументировано и очень наглядно. То что это сделать тяжело, знаю по своему опыту. Читая, статью большей частью описание ассоциировало у меня именно с IDEF0 (кроме бассейна конечно). Этот тип диаграмм помоему набирает популярность, после незаслуженного забвения.
В моем курсе Практика формирования требований в ИТ проектах от А до Я. именно описание функционального проектирование набрало максимальный рейтинг из прочих стадий, хотя я думал будет наоборот.
Описанные тут рекомендации, подходят для построения большинства канонических диаграмм и изложены они аргументировано и очень наглядно. То что это сделать тяжело, знаю по своему опыту. Читая, статью большей частью описание ассоциировало у меня именно с IDEF0 (кроме бассейна конечно). Этот тип диаграмм помоему набирает популярность, после незаслуженного забвения.
В моем курсе Практика формирования требований в ИТ проектах от А до Я. именно описание функционального проектирование набрало максимальный рейтинг из прочих стадий, хотя я думал будет наоборот.
Я читал ваши статьи — познавательно, но очень много материала, так много сразу сложно воспринимать, и мне показалась что часть с функциональным проектированием чуть проще на фоне остальных.
Хотя сам я довольно осторожно отношусь к чисто функциональному подходу, так легко получаются подразделения с «чётко очерченными функциями», но без понятия чем они заняты (функциональный подход), или понимающими чем заняты, но не знающими зачем (процессный подход).
Вот забавная видеоиллюстрация
Хотя сам я довольно осторожно отношусь к чисто функциональному подходу, так легко получаются подразделения с «чётко очерченными функциями», но без понятия чем они заняты (функциональный подход), или понимающими чем заняты, но не знающими зачем (процессный подход).
Вот забавная видеоиллюстрация
я довольно осторожно отношусь к чисто функциональному подходу
Без определения функций системы, можно упустить часть важных потребностей пользователей, которые лежат на поверхности, но мало связаны с основными деловыми процессами. Например, создание и корректировка справочников, возможность настройки вариативности алгоритмов системы и т.д. Отсюда возникает риск не включить их в контракт на разработку и потом препираться с заказчиком за чей счет их реализовывать.
Здесь я соглашусь, в написании требований или прототипировании приложений функциональный анализ действительно полезен. Мой комментарий скорее относился к проектированию бизнес-процессов и планированию проектов, вот где существует опасность начать с функционального анализа и на нём же и остановиться.
Sign up to leave a comment.
Искусство создания диаграмм процессов