-O_o-Кое что не понятно, должностные инструкции, тех. инструкции и пр.... Для чего они мне пригодятся в дальнейшем ??? Ладно тех. инструкции , там понятно, а вот должностные инструкции чем они мне помогут ???
Они помогут понять, как сейчас работает предприятие. В запущенных случаях - как управленцы думают, как работает предприятие. Должностные инструкции как раз и являются перечнем конкретных функций конкретных должностей и их взаимодействия. Если они, конечно, отражают реальные функции и реальное взаимодействие.
-O_o-И вопрос 2-ва (Обязательно оцени рамки системы . ) Что значит оценить ???? Чето не совсем пойму...
Основные "рамки системы" - предприятие в целом. Описание взаимодействий отделов\служб - даст исходную (но очень грубую) модель предприятия. Видимые Вами "хаосные процессы" могут оказаться не таким уж и хаосом, когда Вы взглянете на картину в целом. Дальнейшая детализация и уточнение процессов покажут Вам более объективно как причины появления выявленного хаоса, так и методы его устранения. "Рамки системы" сузятся на наиболее проблемных точках предприятия и позволят более точно оценить как эффект от "наведения порядка", так и затраты на это наведение.

-O_o-,

Ну, как минимум - инструкция рабочая, а не просто "чтобы было" :) На мой взгляд, искать какие либо другие критерии нет смысла: инструкция либо рабочая, либо нет.
Из этой инструкции видно, что оператор участвует как минимум в трех процессах:
1. Поступление товаров от поставщиков - пп5-7
2. Ценообразование - пп8-10 и пп12-13
3. Ревизии\внутренние перемещения - пп6,14,15
Также видно, что в компании есть в том или ином виде контроль качества работ (разделы "Конечный продукт" и "Качественные характеристики"). Кстати, было бы очень хорошо, если эти пункты есть во всех должностных инструкциях. Есть некая система фиксации инциндентов (пп4 и пп11). Соотв. наверняка существует и контроль их исполнения. Есть и некое описание взаимодействия с другими отделами. Соотв. Вы можете получить "цепочку инструкций" должностей, участвующих в этих процессах и получить представление "как есть". Отразив это "как есть" вы получите представление, что конкретно требуется изменить для устранения хаоса (лишние действия, лишние взаимодействия, узкие места и т.д.). И сможете предоставить описание "как надо", заодно оценив и расходы на изменение, и эффективность изменения. Напомню - средство, каким Вы нарисуете схему процесса не настолько важно. Более важно, как правильно заметил S.V: то что вы описали по хорошему должен понимать человек который не обязан знать какую-либо методологию.

-O_o-,

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

Ссылок накидывали здесь уже много раз, даже топик такой есть. Кстати, тот топик второй в гугле . :)

-O_o-Если я Вас попрошу показать мне пример "нарисованного" БП к примеру с ДИ оператора которую я приводил.
ДИ в данном случае - набор функций, являющихся лишь частями процессов. Сами процессы могут быть совокупностью ДИ, или вообще неформализованны какими-либо имеющимся инструкциями.
Или как в Вашем примере с внутренними перемещениями ТМЦ - недоступны для Вашего анализа. И потом, Вы просите "картинку", но не упомянули о выбранном Вами стандарте. И готовности (или хотя бы заинтересованности) руководства в каких либо изменениях. ;) Практически по каждому стандарту есть примеры визуализации процессов, например вот . А погружаться в чужие процессы совершенно не хочется, да и времени особо нету. Подчеркну еще раз - проблема не в том, чем и как рисовать процессы, проблема в том, нужно ли это кому-нибудь еще? Опять же, Вы с такой уверенностью говорите о хаосе в компании, при этом только начав в ней работать и не имея опыта ни в анализе БП, ни в их оптимизации (кстати, Вы не озвучили свою должность). Откуда вы решили, что это хаос, не увидя картину в целом? И почему концентрируете свои усилия именно на чем и как рисовать, вместо выяснения что именно рисовать? Рисуете чем угодно и как угодно, лишь бы это помогло Вам быстрее "погрузиться" в компанию и выяснить как она работает. Лишь после этого Вы сможете предлагать вменяемые предложения об оптимизации. Тогда и встанет вопрос, как оформлять эти предложения, чтобы люди, ответственные за принятие таких решений могли правильно оценивать как сами предложения, так и затраты и последствия их внедрений. И спросите у своего непосредственного руководителя, приняты ли в компании какие-либо стандарты описания БП и если приняты, то какие инструменты используются. Если никакиех стандартов и описаний нет - Вы писали, что знаете VISIO, оно поддерживает IDEF0, SDL, UML, блок-схемы и кучу прочего, в том числе стандартного - вот и рисуйте в ней.

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