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

1-й вопрос краткий. На собеседовании до следующей встречи поставили такую задачу: "Представить верхнеуровневое изображение обработки заявки колл-центра в нотациях: IDEF0, CFFC." Где неподготовленному человеку можно посмотреть понятное описание, как строятся эти схемы? Чтобы как можно скорее выполнить задание.

2-й вопрос более общий. Я не понимал, о чём вакансия, когда был приглашён на собеседование. Не понял толком и во время встречи. После получения задания, формулировку которого я привёл выше, стало понятно: речь идёт о работе, связанной вообще с обладанием представлениями в сфере методологии бизнес-процессо. Вопрос: что лучше почитать/посмотреть, чтобы с наименьшими усилиями обрести начальные представления общего и вводного уровня по теме, чтобы быть способным ориентироваться в работе, когда на неё попаду?

Знаком ли кто-нибудь с курсами:
https://www.coursera.org/learn/systems-engineering-4
https://www.intuit.ru/studies/courses/1055/271/info
https://www.intuit.ru/studies/professional_skill_improvements/1901/info

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

Все курсы стоит смотреть, или какой-то из них более удачный и простой по содержанию, чем остальные?

Если вам известны другие материалы/курсы, не могли бы посоветовать?

Спасибо.

МодальноеОкно,

это правда. Поэтому и спрашиваю. У меня есть догадки, что там будет возможность подучиться прямо на месте, т.к. требования поставили не высокие. Меня попросили только представить диаграммы, и всё. А про прочтение курсов я решил сам. Вот и задаю вопрос. То, что я не владею этим сейчас, они уже поняли, т.к. я им свои навыки достаточно подробно описал.

Подскажете?

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

Я работал в СУБД и именно в BI. Должность называлась "Аналитик". Я не понял точно, почему она так называлась, но по-видимому, данное название было по той причине, что нужно было согласовывать формат отчёта с его получателями и затем писать запрос на извлечение этих данных из хранилища, и строить сам отчёт или автоматизированное средство его регулярного построения.

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

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

Но это только догадки. Об этом я догадался, исходя из требования нарисовать диаграммы IDEF0 и CFFC.

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

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

================

(1) Как я уже написал, моя функция аналитика в бизнес-анализе заключалась в узнавании требований к отчёту, затем уточнении этих требований, затем в результате этого я получал конкретный, чёткий формат отчёта.

(2) После этого я писал (разрабатывал? наверное, так можно выразиться) SQL-запрос, на основе которого из БД извлекаются данные, на основе которых отчёт строится, затем создавал (готовил, разрабатывал) сам отчёт или средство его автоматизированного построения.

Насколько я сейчас понял, я был не только аналитиком. Я был аналитиком в том, что описано в (1), и РАЗРАБОТЧИКОМ в том, что описано в (2). Более того, я был разработчиком трёх составляющих, а не одной:

1. самого отчёта,
2. SQL-запроса,
3. средства построения отчёта на основе результатов SQL-заппроса.

Можно сказать об этом ещё так. По сути, когда я находился в роли аналитика я:

1. сначала получал приблизительное описание, о чём отчёт нужно сделать,
2. затем собирал и уточнял требования в процессе задания дополнительных, уточняющих вопросов тому, от кого поступал запрос на подготовку отчёта, и это происходило до такого состояния, чтобы можно было точно понять, как его разрабатывать и писать запрос к БД,
3. определив точно, т.е. сформулировав точно требования к отчёту, я их передавал себе в роли разработчика.

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

================

Это я написал, что, скорее всего, значит слово "аналитик", в чём его функция.

================

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

================

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

Так вот, когда-то этой формы не было. И других форм, входящих в классификатор (и самого классификатора). И чья-то работа тогда заключалась в том, чтобы узнать эти требования сначала приблизительно, а затем точно, и затем сформулировать их и передать РАЗРАБОТЧИКУ формы, т.е. конкретно человеку, который в Word-е или издательской системе рисует саму табличку, а также в других компьютерных и бумажных форматах. И вот так примерно она, т.е. форма документа, когда-то и появилась и была разработана.

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

Таким образом, получается, что если бы не было аналитика (того, кто точно собрал и сформулировал требования), то не только разработать было бы нельзя, а кассиру и клиенту банка самим бы приходилось каждый раз думать и решать, что правильно написать в документе. Сумму с копейками писать или без? Название документа писать или не писать потому, что и так понятно?

================

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

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

================

Таким образом, аналитик создаёт процесс, то, как он должен быть устроен. А специалисты/работники только его выполняет при уже имеющихся, созданных требованиях.

Я правильно понял?

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

Т.е. то, что я описал в предыдущем посте, относится к СОЗДАНИЮ участка работы. А то, что имею в виду сейчас, - это ПРЕДОСТАВЛЕНИЕ информации об УЖЕ ИМЕЮЩЕМСЯ участке работы.

Не знаю точно, но так догадываюсь. Как вы думаете, так ли всё это?

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

То есть, два вопроса теперь: насколько правильны мои представления в последних трёх постах и как быстрее всего понять IDEF0 и CFFC. Был бы рад увидеть ответы.

Уточню ещё вот что. Мне либо предстоит заниматься тем, что я описал, либо там будет что-то очень сильно имеющее отношение ко описанным функциям.