Для этого моими предшественниками был разработан целый регламент «Как описывать бизнес процессы». В нем все было конкретно. Рисуешь такую-то схему, делаешь к ней описание, прикладываешь печатные формы документов, инструкции по их заполнению, образец заполнения, ролевые инструкции и еще кучу других документов. В результате на один процесс получался нехилый такой пакет документов.
Скажу сразу, раньше я такого никогда не видел. Я конечно слышал, что есть PMI PMBOOK, и даже прошел соответствующий курс. Что есть 34-й и 19-й ГОСТы. Что есть технологии бережливого производства и экстремального программирования. И какие-то из рекомендаций я пытался применять на разных проектах. Но не было главного — единой методологии, которую можно было бы начать использовать.
В основном приходилось работать по образцам документов, которые раньше делали для какого-то клиента. В каждом проекте добавляется что-то новенькое. Ничего особенно не контролировалось поэтому широко применялся авторский подход разных специалистов при формировании проектных документов. Не было единой системы и методологии подготовки каждого документа. У многих ее нет и сейчас.
Например, у Вас есть шаблон формы «Отчет об экспресс-обследовании»? Есть? Отлично. А пример заполнения? Тоже есть? Замечательно. И конечно же у Вас есть инструкция по заполнению данного отчета. Просто удивительно. И последний вопрос: у Вас прописана технология подготовки данного отчета? Я в шоке. Вы скорее исключение.
Поэтому, поймите мое изумление, когда я увидел данный стандарт. Мысленно я снял шляпу перед теми, кто его составлял. Его можно было сравнить с процедурой запуска ракеты. Где все этапы были подробно прописаны и нормированы. Для новых сотрудников — просто незаменимая вещь. Делай по инструкции в нужные сроки, заполняй такие-то формы и получишь результат гарантированного качества. Точнее получишь полностью описанный бизнес-процесс.
Много позже я столкнулся с такой постановкой дела только на промышленных предприятиях. Где в технологии производства каждого изделия были прописаны необходимые операции. И то видел не на всех, а в основном тех, где работали специалисты еще старой, советской закалки. Ну да это другая история.
Вы, конечно же знаете, что при выполнении проектов требуется провести анализ автоматизируемых бизнес-процессов. Так вот, в этом направлении ИТ компании прошли совсем маленький путь. Я думаю, что это связано с тем, что команда, сформированная на проект, не обладает необходимой компетенцией. Не секрет, что выполнив проект, команда расформировывается и затем редко собирается вместе. В результате не получается использовать и, главное, накапливать компетенции и навыки. Я уж молчу про методологию.
Так вот на этом предприятии команда была постоянная и занималась одной деятельностью — выпеканием бизнес-процессов. И качество их было очень высокое. А вот как оно достигалось я сейчас и расскажу.
Итак, в процессе работы над бизнес-процессом, например процессом «Оценка качества доставки», в рабочую группу включались руководители отделов, которых данный процесс затрагивал. Далее с каждым из них проводилось интервьюирование, затем прототипирование и формализация. И готовился документ, опять таки известной формы. Далее этот документ внимательно изучали и правили. Внимание уделяли каждой детали. Какого цвета линия на схеме, как пронумерованы процессы, шрифт, логика и так далее. Далее документ подписывался членами рабочей группы. И вот, таким образом, шла работа над каждым документом.
Для меня это было в новинку. Не секрет, что на многих проектах документы формируются не самым должным образом. И принимаются и отправляются клиенту практически после первой редакции. Соответственно и ошибок в них немерено. Это, в свою очередь, компенсируется нежеланием ответственных сотрудников и клиента и ИТ-компании вникать в детали. А почему, я расскажу в другой истории.
Так вот, в результате появлялся пакет документов на бизнес-процесс. Еще раз внимательно проверялся и подписывался всеми членами рабочей группы. Я еще раз проверял, ставил свою подпись и нес такой процесс на утверждение президенту компании.
И вот тут начиналось самое интересное. Президент начинал вникать в процесс. При мне. Очень подробно. Он сравнивал шрифт со стандартом, проверял логику процессов, контролировал соответствие названия процессов в схеме, в описании, в ссылках в документах и ролевых инструкциях.
Например, в схеме процесс имеет имя: «П01 Звонок клиенту», а в описании имеет имя: «П 01 звонок клиента». Попробуйте найти ошибку. Нашли? Сколько ошибок? 1? 2? 3? Молодцы, именно три ошибки. Давайте считать.
1 ошибка: пробел между буквой «П» и цифрами «01»
2 ошибка: слово «звонок» с маленькой буквы
3 ошибка: не правильное окончание слова «клиента»
Дело тут не том, как нумеровать, хотя на это тоже был отдельный регламент, а в том, что процесс должен иметь одинаковое название везде, где на него имеется ссылка.
Собственно после того как ошибка была найдена президентом, дальнейшая проверка прекращалась. Всем кто подписал документ автоматически шел штраф 100 баксов. И весь пакет документов отправлялся на переделку. Это был единственный руководитель, который, за всю мою практику, ТАК проверял документы.
В месяц у меня стабильно 500-1000 баксов на штрафы уходило. Дело даже не в штрафах, а в том, что весь пакет документов надо было править, затем заново согласовывать и подписывать. Это было очень трудоёмко.
Это было непривычно. Я ругался, матерился (про себя конечно). И шел на второй круг. Затем на третий, четвертый и так далее. К пятому мне было абсолютно все равно, есть там ошибки или нет. Я видеть не мог эти процессы. Они мне снились. Я во сне рисовал схемы и корректировал документы.
Меня хватило на полгода. Затем были новые компании и новые проекты. И никто из руководителей после не уделял столько внимания документам. И вдруг я заметил такую особенность. Каждый раз когда я готовлю какой-нибудь документ, я автоматически проверяю его правильность. Я сразу же вижу ошибки и исправляю их. А уж про документы, которые готовили консультанты на проектах, я вообще молчу — там столько ошибок. Жаль, что я не мог их штрафовать. Поэтому ограничивался указанием на самые критичные. Особенного смысла в них вкладывать своих усилий не было, потому что завтра они уйдут на другой проект и может с ними я никогда больше работать не буду.
Источник: группа «Записки внедренца 1С» (http://www.facebook.com/groups/Zapiski/)
😎 Знакомая ситуация. В России только так и можно наладить процесс. Но к сожалению в реалиях при обычной текучке кадров и быстром изменении бизнес процессов, подход будет съедать сам себя. Хотя подход по ГОСТам и мекам весьма хорошо проработан, может только не так современен.
(0) О чем статья?
1. О том, какая задница президент?
2. О бюрократии?
3. О том, что документация быть должна?
…
А эти бизнес-процессы потом в жизни использовались или лежали мертвым грузом, как никому ненужная документация?
(3) nataon, Процессы периодически пересматривались и актуализировались. Велся архив процессов и всех изменений к ним. Хотя, если бы не интерес в этом главного президента компании — они бы быстро прекратили свою жизнь.
(2) awk, просто история из практики. без морали.
(1) у кого то проработан, у кого то нет. В основном нет. а чисто по ГОСТам работать нереально. Слишком много возникает вариантов того, как можно выполнить конкретный пункт из ГОСТа. Поэтому нужна методика его применения. Или, при ее отсутствии, собственный авторский подход к толкованию ГОСТа
verter.me развёл бюрократию
Человека штрафовали на 500 баксов, а он работал. Полгода. Эта тема не для одинэсников.
(7) PiccaHut001, всего лишь подчинился требованиям президента. Полгода подчинялся и платил штрафы. Потом вспоминал как дурной сон. Но навык с тех пор стал вполне устойчивый. А насчет бюрократии — правда Ваша. Пока соберешь весь пакет документов — несколько потов с тебя сойдет.
(8) Aleks1973, не только меня штрафовали. Но мы хотели быть лучше. и работали над собой.
(6) verter.me, только на тех предприятиях, которые имеют советское наследие. Я по молодости нарвался на проект в проектной организации. После пары месяцев, я знал о ГОСТах всё. Правда спать стал плохо, т.к. отодрали меня там по полной 🙂 Потом даже с одним моим знакомым, который создал 1С ЕСИС, создали 1С ЕТИС, и неплохо в дальнейшем использовали. Более того, сейчас я сам выработал методику, которая позволяет мне делать всеобъемлющее детальное техническое задание, без обеспечения проекта сотнями страниц технической документации. Сколько раз уже задницу спасало, не перечесть. Описывать конечно не буду, главный принцип простота и лезвие Оккамы и схемы, схемы, детальные схемы, желательно простые и понятные, без привязки ER, RUP. Можно даже сказать придумал свою модель 🙂
В месяц у меня стабильно 500-1000 баксов на штрафы уходило.
verter.me, нескромный вопрос:
ты какой стране работаешь
(или в каком «отдельно взятом» городе)
😉
(11) Ключевое слово «сам выработал методику». Хорошо что было кому драть нас. Потом все наши штрафы и затраченное время окупилось сторицей
(10) Представляю сколько зашибаешь, если так пишешь … и ещё время сидеть на форуме…
Подай милостыню 100500 Р бедному одинэснику!
(12) yuraos, Россия, Москва. С 2006 года. До этого в одном из городов на Севере — Архангельск
(14) Aleks1973, А я параллельно. Пока программа выполняет сценарий можно языком потрепать.
И, кстати, слова «бедный» и «одинэсник» — как то не камильфо. Везде спецов не хватает, а ты прибедняешься.
(16) verter.me, ключевое слово «спецов». Одынэсников навалом.
(16) Если ты предлагаешь например 55 за УПП то понятно будет нехватать.
(18) Aleks1973, Думаю при выборе спеца — стоимость играет не первую скрипку. за 55 спец даже с дивана в Москве не встанет. Так что пример не жизненный. И что понимать «за УПП». УПП — она большая.
(15) verter.me,
значитьс так сказать в метрополии…
надо полагать что в Архангельске тебя так не штрафовали?
🙂
(19) yuraos, в Архангельске я работал на себя. некому было меня учить. и штрафовать. И вообще данный пример со штрафами — единичный. за мою 12 летнюю практику — нигде больше не штрафовали. Но те штрафы я сейчас рассматриваю как инвестиции. Они давно уже окупились.
фанатизм — это плохо… если по простому — деньги на ветер.
Всё должно быть в меру,. на высшем уровне и с вниманием к деталям — но без фанатизма. Как к это приучить себя и сотрудников? Хз… Но точно не штрафами. Ибо после штрафов самые адекватные и толковые тупо увольняются. И мы возвращаемся опять к первому тезису, что фанатизм — это деньги на ветер.
(22) romansun, Рассказываю как. Штрафы конечно нет. разбегутся однозначно. А вот контролировать документы по проекту — надо. и отправлять на доработку. и еще раз. и еще раз. Через некоторое время навык у сотрудников формируется. С нуля на это уходит около 2 месяцев. В дальнейшем при работе в постоянной команде, навык переходит в привычку. Главное смотреть документы — и отправлять на переделку. Даже если цвет линии не соответствует нужному.
(23) verter.me,
как говорится ввалить сукинам детям!
но без излишьнего фанатизма — чтоб откачали
😉
(0) Все правильно кроме одного — бизнес не статичная система процессов а динамический организм с массой внешних воздействий. Любой процесс устаревает как только изменился хоть один его элемент. Представляйте процесс водой которую мешают в неустойчивой кастрюле с кучей предметов внутри.
есть — напечатать документ 1 и передать сотруднику 2 в 15.00, напечатать документ 2 и передать сотруднику 4 в 16.00
а есть — подготовить комплект документов 1,2 и 4 в установленные сроки (список документов отдельно со сроками) и передать ответственным (список отдельно)
первый — уже описание тех процесса а второй регламент.
что из них проще потом править?
(25) iov, Пример не корректный. Печать некого документа — это следствие, а причина это выполнение операции, например «Прием заказа». В организации процессы не меняются как вода. Всегда существуют устойчивые процессы, например «коммандировка сотрудника» — они редко меняются. Если конечно компания не меняет основные направления деятельности каждый день.
(26) — это кусочек так сказать — и причем конкретный — сам процесс и есть печать (операторы подготовки первички)
только там слов побольше. 😉 но суть таже — менялись документы — формы и порядок. И система справок и инструкций оказалась более гибкой чем монолитная.
Но опять же коммандировка — живой пример 2 месячной давности. Сломался процесс — человек из 1 коммандировки уехал в другую сразу- без сдачи документов и процесс поплыл…
Мы все свидетели постоянно и быстро меняющейся ситуации — но продолжаем создавать нечто — на года и века.
(26) Вы интересно пишете — надеюсь удастся обсудить что-то на
(27) iov, Приведенный пример — частный. С ним вполне справится сотрудник бухгалтерии. А вот если данный случай становится постоянным — тогда он требует систематизации и разработки правил. Ради одного случая нецелесообразно использовать ресурсы ИТ специалиста.
(28) iov, Возможно. не определился пока
(30) Именно то этих маленьких случаев — много и тогда как быть директору? Бухи жалуются что программист/специалист плохой и ничего не делает, а программист/специалист просто показывает должностную инструкцию в которой нет пункта- поработать за бухгалтера головой. Кто виноват?
(30) Ну что вы как руководителю проектов вам и не приехать? Заведете нужные знакомства покажете себя — посмотрите на других. Я надеюсь вы воспринимаете наш диалог именно как диалог. Потому как мне не о чем с вами спорить — Вы правы и я прав так как находимся на одной стороне. Просто интересно узнать видение проблемы несколько под другим ракурсом.
(31) iov, Могу посоветовать лишь систематизировать все жалобы. А затем уже смотреть что происходит в реальности. При необходимости лично выполнить работу бухгалтера, чтобы понять в чем проблема. Если бухгалтера жалуются — это хороший признак. Они в Вас еще верят!
(32) iov, (32) iov, Наверное Вы правы. Стоит рассмотреть посещение евента в этом ключе
(33) О нет я не настолько бессердечен и расчетлив чтобы не помогать людям. конечно я стараюсь выяснить где корень проблемы. Но когда в решении её заинтересован лишь -я тут встает вопрос, а нужно ли?
Скажу коротко.1с и ГОСТ понятия не совместимые.
(35) iov, Обязательно нужно, Александр! если время свободное есть. Это Ваши вложения в свой опыт и свои навыки.
(36) ranger, Спорное утверждение Марат. есть проекты где работа по ГОСТ обязательна. Например проекты гособоронзаказа. Хотя, согласен, документы формируемые по ГОСТу носят в большинстве своем формальный характер.
Есть еще один момент — очень часто для того, чтобы иметь рычаг давления на ИТ-компанию, надо настаивать на включение в договор пунктов, в которых указывается какие разделы из ГОСТа нужно в проекте обязательно исполнить ИТ-компании. Это один из способов сделать так, чтобы проект шел за счет ИТ-компании.
(38) Андрей,чтобы Вы поняли о чем я говорю,нарисую вам «самолетики»:)
Вернее их нарисовал другой человек и прекрасно изложил в статье
Особо стоит обратить внимание на раздел «А нужно ли вообще техническое задание? А Технический проект?»
Кстати,стандарт моделирования описанный в этой публикации очень похож на ГОСТ «МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ IDEF0″,который ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России в 2000 году.
(0)Хороший старт на Инфостарт! :)))
Сразу несколько отличных статей. Правда чуток коротковаты 🙂
Но понравились.
(5) verter.me, ну что же так, без морали?
На мой взгляд все логично. Есть причина и следствие, есть долгосрочный результат.
И всем должно быть понятно благодаря чему он достигнут 🙂
(39) ranger, В данном случае — ответ один — зависит от проекта. На крупных проектах ТЗ обязательно.
Аргумент такой — на больших предприятиях очень много сил влияния. И внедренец, дабы не попасть в сложную ситуацию по разборке между двумя силами, должен иметь рычаг влияния. ТЗ как раз тот самый рычаг.
В маленьких компаниях с одним центром силы — можно внедрить проект за счет собственных сил. Без излишней бюрократии. Вполне допустимо использовать технологии из экстремального программирования и Agile.
(41) СергейКа, Спасибо Сергей.
Истории задумывались именно как случаи из реальной практики. Без морали. Просто истории. Типа сказки.
Пробуем, всему свое время. В некоторых историях есть локальные выводы.
Над объемом поработаем.
Красиво написано, однако…
Во, в этой статье я хотя бы уловил смысл:
По-моему менеджера который штрафовал бы консультантов за ЭТО надо увольнять, притом немедленно. Конечно в госконторах и конторах вроде газпрома люди этим занимаются, и прикиньте, им за это платят.
Притом самое интересное что этим занимаются как правило на этапе бизнес-анализа и проектирования, который предшествует этапу разработки и который нельзя распарралелить, этим просто весь проект сдвигают в … вообщем в совсем другие сроки.
(45) comol, Согласен, Олег если уделять внимание деталям — сроки будут сдвигаться. Но и халтуру после первой итерации гнать наверное тоже не стоит
(37)Времени то и нет….
(0) Цитата :
«Например, у Вас есть шаблон формы «Отчет об экспресс-обследовании»? Есть? Отлично. А пример заполнения? Тоже есть? Замечательно. И конечно же у Вас есть инструкция по заполнению данного отчета. Просто удивительно. И последний вопрос: у Вас прописана технология подготовки данного отчета?»
Чем отличается
«инструкция по заполнению данного отчета» и
«технология подготовки данного отчета» ?
(0) Цитата :
«Печать некого документа — это следствие, а причина это выполнение операции, например «Прием заказа».»
Операции ближе к входу бизнес-процесса — это, значит, причины , а ближе к выходу — это, значит , следствия . Так ?
Это Ваше личный подход к декомпозици бизнес-процесслв ?
Может быть , ссылки какие-то приведете.
(45) comol,
В восточных единоборствах есть правило: сначала изучается какая-нибудь техника ведения боя, но высший уровень овладения техникой является свобода от нее.
Так и в данном примере: был привит некий навык, корни которого сохранились даже тогда, когда автор отказался от полного следования технике.
Два своих подобных примера:
Пример 1. При проверке дипломных наш декан, найдя три ошибки на листе, возвращал его студенту, не читая дальше. На возражения типа: «Машинистка ошиблась», он отвечал: «Диплом получаете вы, а не машинистка».
Пример 2. У мужа при проверке курсовых работ (с кучей чертежей!) его преподаватель находил нечто не подписанное и тут же сверху писал «апельсин». Работу приходилось переделывать.
Антипример 1. Начальник (!) экономического отдела делает расчеты, которые приходится выборочно перепроверять финдиру. Иной раз финдир вынуждена делать их сама (если результат очень важен). Почему не уволят?! А другие хуже.
Штрафы — это, конечно вынужденная мера, но иногда единственная (иногда так жаль, что нельзя людей оштрафовать за их ляпы, которые ищешь потом пол дня, чтобы доказать, то не правы они, а не 1С… Не совсем в тему, просто наболевшее:((). Но, кроме штрафов, руководитель и премировать сотрудников может за качество выполненных работ (ту же документацию с первого раза и без ошибок)
(50) PAVI, Так вы считаете что пробелы в названиях всё-таки нужно проверять? ИХМО одно дело это цифры в финансовой отчетности, а другое дело — названия пунктов в описаниях БП…
(46) verter.me, ооо… так вот правда жизни в том, что как правило там где документация очень красивая и правильная, без помарок — это халтура. Люди потратили тонну времени чтобы поправить все помарки, но при этом не нашли время даже со всеми ключевыми сотрудниками интервью провести… вот такое сплошь и рядом… а когда в документации схемы, которые «выстраданы»… которые 10 раз переделывались после каждого нового интервью. Там будут помарки, но я бы лично предпочел такой комплект документов 🙂
Браво! Я бы в ноги поклонился такому руководителю! Ибо, если бы все или хотя бы большинство руководителей были с такими подходами, то мы бы жили сейчас в другой стране.
О сроках. Сроки всегда нужно закладывать: а) реальные для качественного выполнения работ, б) с запасом.
Я всегда, оценив какую-либо работу, умножаю на 2 и время и стоимость…
(53) comol, множественные опечатки, помарки и т.д. — это признак недоработки. Значит человек мог допустить еще какие-то ошибки. Проблему можно решать либо через спец. ПО с гиперсылками (например, что типа wiki-библиотек), либо какими-то другими способами.
И такое придирчивое отношение к оформлению — это правильно, особенно на начальном этапе работы, чтобы приучить сотрудника к определенной системе.
Просто чем больше автоматизация, тем меньше требований к пользователям, тем меньше их квалификация и тем меньше они задумываются над своими действиями и результатами. А правильная инструкция позволяет снизить вероятность ошибок. Кроме того она же позволяет избежать потери «сакральных данных» при уходе сотрудников.
Знакомая работала в УФМС по Северо-Западному округу. Отдел аналитики и статистики.
1. Вся работа отдела из 10 человек состояла в получении и забивании «циферок» в экселевские формы. — ее можно было свести к минимуму и оставить всего 1-2 операторов но с нормально зарплатой (не 8000 руб., а 20000-25000 руб.) или вообще все сделать через web-интерфейс с аккамуляцией данных сразу в Москве.
2. Сбор и анализ данных по расплывчатым инструкциям. Причем строгой (в «математическом» смысле, с поэтапной с экранами и т.п.) инструкции по заполнению того или иного отчета как не было, так и нет. И при уходе человека в отпуск начинается тихая паника у начальника и страх сотрудниц — «на кого кинуть эту муть».
В налоговой то же самое: ИФНС по Санкт-Петербургу. Единственное отделение где выполняется регистрация организаций и ИП и их изменение, ликвидация и т.п. Операционисты — зарплата 6000-12000. Четких инструкция по правилам, есть каие-то общие правила, оформления входных документов нет. И операционисты исходя из собственного опыта и настроения подсказывают особо явные ошибки. Можно было бы сделать все это через web-интерфейс с автоматической проверкой всех данных.
Сайт госуслуг вроде бы этим и занимается, но все равно после заполнения всех пунктов идет ручная проверка — а это значит четких инструкций нет.
P.S. Все зарплаты до уплаты НДФЛ.
Автор статьи, видимо, забыл цель этого форума, и зарабатывает дешёвые деньги и авторитет флудом. Что ж, удачи!
Ну и о чем эта статья? Где хоть какие-то выводы, помогающие общей цели сообщества? Просто за жизнь поговорить хотели? Так тут вам не ЖЖ, с этим туда, пожалуйста.
(55) AShley,
. А не действиями вида «я не буду разбираться но до формата докопаюсь».
(57) Программист 1С, Согласен. Статье всё-таки «-«… «ниочём».
(11)
Поделитесь, если не жалко.
Можно в личку.
Я когда пришел в компанию работать программистом (до меня работали фрилансеры). Я начал приучать народ к ТЗ. Приинял ТЗ от пользователя, расписал, подтвердил у ответственных, подписи собрал у ответственных и приступил к кодингу. Так вот это прожило примерно месяца два, после чего ген-дир пришел и сказал, давайте оставим эту бумажную бюрократию. Конечно когда все расписано круто, но на это надо иметь: время, силы, штат что в большинстве контор к сожалению нет.
Познавательно. Но думать бухгалтеры как это сделать не хотят. Лучший вариант покажите что вам надо и каждую строчку дальше из них выбиваешь откуда взять. Если не откуда взять, пробуешь, эксперементируешь и бежишь утверждать куда сам придумал положить.
(48) Ish_2, В инструкции указывается какая информация должна быть и в какой ячейке (поле). В технологии описывается как собрать такие то данные для этого отчета. У кого собрать. Как их обработать.
Вообщем описывается процесс подготовки отчета.
Простой пример. У вас новое предприятие. Вам необходимо через 5 дней выдать отчет по его обследованию. 2 дня Вам выделяется на работу на объекте и 3 дня на подготовку отчета. Вопрос что вы будете делать в 1-й день? во 2-й день? С чего начнете?
Вот на эти вопросы и дает ответ технология. Иногда отсутствие технологии компенсируется личным опытом того, кто проводит обследование предприятия. У него выработалась своя технология.
А вот для тех, кто первый раз ее проводит — технология то и нужна.
(49) Ish_2, Хорошо я подготовлю пример
(53) comol, Спорное утверждение. Иногда документацию смотрят по красоте. Разглядывают схемки, графики, рисунки. Показывают твоим же конкурентам (типа на независимую оценку), а уж они то всегда рады указать на твои ошибки и подправить свои.
(57) Программист 1С, Честно говоря, Вадим не ставил такой цели. Я еще не в курсе что за деньги я тут заработал. Надо будет уточнить. Спасибо за новодку. А про классификацию статей — тоже заранее не знал. теперь я услышал новое слово «флуд».
(52) comol, маленькая деталь в статье приведён пример ошибки, где перепутан «звонок клиента» «и звонок клиенту» Перепутано направление звонка. Это серьёзная ошибка.
В советские времена Вы не работали? В режимных институтах вся документация готовилась таким образом. А сейчас орфографические ошибки в служебных записках, договорах, в ТЗ – обычное явление, а уж про семантические и стилистические…
(69) irishka77, В советские времена еще не работал. Поэтому негде было навыков правильных набраться. И не у кого. Это был первый случай. Все тогда только учились делать проекты. А вот чуть позже, когда удалось поработать на проектах для оборонки, я действительно увидел КАК НАДО работать с документацией. На тех заводах еще работают люди с советской школой.
А мне статья понравилась, очень даже «о чем». Неужели надо делать выводы, как для первоклассников? Статья поучительная. С автором полностью согласна, что приобретенный опыт с въедливым директором в дальнейшем сформировал у него необходимые привычки для качественной работы.
Не верю!
Во-первых, в такого презедента.
Во-вторых, в то, что при таком призеденте и таких штрафах, не дошло дело до АРИС или БизнесСтудио.
(72) via64, Ну почему же. Процессы рисовали как раз в Aris. А Бизнес-студио наверное тогда еще не было. Это был 2008 год. По крайней мере в той функциональности, которая у него сейчас есть.
А насчет верю — не верю. Посмотрите на прикрепленные файлы
Я не так подкован, как автор, имеющий, видимо, обширный опыт участия в проектах, но то, что описано в (0) — должно быть! пытаюсь у сеюя хоть что-то похожее внедрить, но идет тяжело. в «одно рыло» и писать регламенты, и программить, и запускать это все — получается непросто. Но описывать надо хотя бы потому, что в результате самого процесса описания становится понятным — скольо отовсюду стоит костылей и на каких ниточках все держится… 😉 А в отпуске хочется жить отпуском… 😉
(73) verter.me,
Тогода, всё, должно было бы быть не так уж страшно. При той степени продвинутости презедента, о которой Вы говорите, наверняка, был документ «Соглашение о моделировании», в котором оговаривались толщина, цвет линий и прочих элементов модели. Всё это настраивается в АРИСе.
(75) via64, Вы правы Виталий. Был такой документ. Может назывался немного по-другому, но был. Проблем с Arisom практически не было. Однако в Arise мы рисовали только процессы. Всю остальную документацию делали в MS Ofice. И проблемы возникали в согласованности всей документации. Пример типичной ошибки в статье приведен. За что и получали штрафы. ))
Увидеть бы образец той пачки документов по описанию бизнес-процессов. А то очень актуально внедрить такое на предприятии, когда все меняется задним числом и очень часто.
(77) Pushast, Обратите внимание Наталья на 73 сообщение. В нем приложены фотографии структуры пачки документов. Может быть это Вам поможет.
ик, ну нефигасебе, я такое не сотворю в принципе…Тут с 3 справочниками месяц мозг выносят…
…а пункт 8-й — он последний?
(79) Pushast, Нет )) там есть еще пункт 09 «Оценка рисков по методике COSO» пункт 10 «Сопровождение клиентов по методике ITIL» пункт 11 «Методология выполнения проектов Agile»
Вообщем Ужас! Ужас! Ужас!
(0)
1 ошибка: пробел между буквой «П» и цифрами «01»
2 ошибка: слово «звонок» с маленькой буквы
3 ошибка: не правильное окончание слова «клиента»
4. «П01 Звонок клиенту» не является процессом 😉
О чем статья?
(81) Chernik, Спорное утверждение. Можете привести критерий по которому Вы определили, что «П01 Звонок клиенту» не процесс? И, если можно раскрыть свое утверждение подробнее