Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Моделирование бизнес-процессов в нотации BPMN. Часть II. Практикум в BPMS: Bizagi Digital Platform
Опрос

Вы используете

Библиотека

17.09.2015 20:42
  от автора
  Lalunavlz

Как сделать так, чтобы ваш регламент прочитали

Оценки за материал: 3.50 (2)

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

Что же нам на это говорят словари:

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

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

Если уйти от сухого языка словарей, то в голове нужно четко делить: бизнес-процесс – это то, как алгоритм работает в жизни, а регламент – это документ, который его описал. Регламент – это сценарий, а бизнес-процесс – это снятый фильм. В статье речь пойдет именно о регламентах, о сценарии.

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

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

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

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

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

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

Чаще всего ответ будет «один раз написать и забыть об обучении тех, кто участвует в процессах». Если вы описываете процесс для этого – это очень хорошая цель и полезная бизнесу. Обученный сотрудник – это сохранение ресурсов в будущем на переделки за плохо обученными сотрудниками.

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

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

Если же вы описываете регламент, который не решает никаких проблем. «Летит» процесс и так неплохо, просто нужно описать, то нужно приложить все усилия, чтобы не описывать его. Это пустая трата ваших ресурсов.

Вот вы договорились сами с собой, зачем вы пишете регламент, как вы будете его наполнять?

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

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

Так же при написании регламента следите за уровнем детализации. Не нужно писать в одном регламенте на какие кнопки нажимать, когда формируешь отчет в 1С, и какое-нибудь важное согласование, с большим количеством участников, «загнанное в цикл». Это операции разного уровня, у них разные читатели и этим разным читателям не интересно читать подробные инструкции операций низкого уровня. Если что-то не интересно или нечитаемо, считайте, что это уже не работает. Все правила работы с программным обеспечением, сложного заполнения документов (не за исключением поставить подпись и печать) лучше выносить в приложения. В хорошие, подробные, очень желательно с картинками, приложения.

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

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

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

1.      Не игнорируйте реальную работу в рамках бизнес-процесса. Помните про сценарий к фильму? Во многих картинах импровизация стала изюминкой фильмов и сделала их любимыми. Не бойтесь править регламент под реальную жизнь!

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

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

Спасибо за внимание,
Ильченко Ольга
г. Волгоград

Комментарии

Оценки: /
18.09.2015 06:35
  от автора
  Репин
Здравствуйте, Ольга!

Рад, что Вы нашли время написать новую статью. Спасибо!

С уважение
Владимир
Оценки: /1
26.10.2015 12:19
  от автора
  ciatco
Добрый день!
Я долго думал писать комментарий или нет, но все таки решился
Неплохая в общем статья, но:
Неправильная постановка задачи на начальном этапе ведет к неверным результатам, даже если инструменты выбраны идеально, и так же идеально проведена вся остальная работа.
У физиков-теоретиков есть такая шутка - сферический конь в вакууме не ржет, не ест и не брыкается, а в реальном мире еще и не существует, но мы вам расскажем как это все устроено и с удовольствием покажем как работает.

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


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


Летчик не читает инструкции на боевом задании как летать на данной модификации самолета, какая кнопка чего запускает и какие лампочки по какому поводу моргают.
Априори предполагается, что он этому всему обучен и все умеет делать профессионально.
Аналогично и бухгалтер не листает каждый раз методичку по правилам оформления той или иной операции.
Операторы в Макдональдсе, хирург за операционным столом, токарь, мерчендайзер, финансовый директор ... - как часто Вы видели их листающими инструкции по своей непосредственной деятельности?
Как часто кто-то перечитывает инструкцию к пульту от телевизора, или справочную информацию Word, на худой конец какой-то ГОСТ?

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

Другое, на мой взгляд, ошибочное предположение:
В нелегком деле описания процессов нужно помнить не для кого вы это делаете, а кто будет этим пользоваться.

А это разве не одно и тоже?

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

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

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

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

3. Аудит.
Для того чтобы понять, что и как проверять, надо с этим как-то познакомиться.
Или освежить память, как оно там примерно работает и какие показатели смотреть, а на что можно даже не заморачиваться.
И, естественно, при "разборе полетов".

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

Это напоминает анекдот -"после сборки тщательно обработать напильником".
Бумажки должны полностью отражать работу, в противном случае, что же регламентируется?
И делать бумажки надо так, чтобы они полностью отражали работу, а не были бы просто похожи, или даже очень похожи.
Мы, например, генетически мало чем отличаемся от червей, а от обезьян не более чем два соседа по лестничной клетке отличаются друг от друга.
Степень "похожести" в этом случае играет ключевое значение.
И мерседес и лада-калина суть - автомобили, но как говорится "есть один нюанс"

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

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

Чаще всего ответ будет «один раз написать и забыть об обучении тех, кто участвует в процессах». Если вы описываете процесс для этого – это очень хорошая цель и полезная бизнесу.

Обученный сотрудник – это сохранение ресурсов в будущем на переделки за плохо обученными сотрудниками.

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

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

Если же вы описываете регламент, который не решает никаких проблем. «Летит» процесс и так неплохо, просто нужно описать, то нужно приложить все усилия, чтобы не описывать его. Это пустая трата ваших ресурсов.

Вот вы договорились сами с собой, зачем вы пишете регламент, как вы будете его наполнять?


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

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

...груда никому не нужной макулатуры, за которую кто-то несет ответственность и служит только для наказаний «в случае чего»

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

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


Никакой регламент, даже самый идеальный, не решит никаких проблем возникающих м/у исполнителями, особенно если исполнители [не]могут/[не]хотят договориться/поругаться/спустить на тормозах и тп.
Для того, чтобы процесс протекал гарантированно по каким-то правилам, регламент вообще не нужен.
Необходимы инструменты, которые бы позволили, как минимум, выявить и зафиксировать отклонения, желательно автоматически и в реальном времени.
А в идеале - позволяли бы осуществлять только регламентируемые действия и сразу реагировали и корректировали любые отклонения.
Поясню на примере:
Возьмем процесс приема ТМЦ на склад.
Необходимо сделать простую операцию - принять, разгрузить и отпустить автомобиль.
Набор операций элементарный:
1. КПП на въезд - надо как-то зарегистрировать машину и запустить на территорию.
2. Весовая БРУТТО - предположим товар весовой, значит нам нужна масса БРУТТО, и мы как-то это фиксируем.
3. Склад - разгрузка товара и фиксируем что разгрузились и что номеклатура соответствует.
4. Весовая ТАРА - фиксируем тару и проверям что вес совпадает с указанными в документах.
5. Регистрация накладных - бухгалтер проводит соответствующие проводки.
6. КПП на выезд - фиксируем и проверяем, что машина пустая и выпускаем.
Казалось бы простые операции.
Даже весы можно подключить к компьютеру, чтоб не вручную считать, и RFID со штрих-кодами на внедрять, но:
Что произойдет, если например бухгалтер не в тот же день оформит документы?
Что произойдет, если на один физически зашедший автомобиль, подложат 2-3-4-... набора документов?
Будет ли у оператора возможность изменить вес автомобиля/груза, а в последующем бухгалтер заменит сопроводительные документы?
Что будет, если водитель немного съедет с платформы весов при взвешивании?
Что произойдет, если все участники будут в сговоре?
Что произойдет, например, если не будут пройдены все этапы в установленной последовательности, а только бухгалтер на 5 шаге что-то проведет?
Усложним немного задачу - у вас не 1 машина, а скажем 300-400 за смену, как будет работать процесс в таком случае?
А если через эти же точки будет осуществляться и отгрузка ТМЦ и готовой продукции и общий объем возрастет до 500-1000-... автомобилей?

Имею личный опыт закрытия схемы для реализации которой необходимо было не менее 11 человек для того чтобы провести всего лишь 1 комплект фиктивных документов на сумму 1500 USD (1 автомобиль с сырьем).
При этом 7 человек из числа сотрудников предпрития (целая смена) и 4 внешних агента (контрагент, перевозчик и как минимум 2 водителей) - деньги надо как-то обналичить.
Фирма работает исключительно по белому и у них нет даже кассы - все операции исключительно по контрактам и через банк.
Регламенты прописаны и даже имеется сертификат ISO - не купленный, а настоящий.
Службы охраны своя во главе с целым полковником КГБ (правда в отставке) и есть еще внештатная служба охраны.
Имеется свой собственный аудитор, который регулярно устраивает проверки плановые и внеплановые.
Если люди решили договориться, не то что регламенты, но и никакая служба охраны и видео камеры с собаками не помогут.

Протекание самого процесса [не] по регламенту можно выявить исключительно только в момент совершения какого-то конкретного действия для конкретной транзакции при прохождении контрольных точек.
Если проверять постфактум, то все будет выглядеть идеально и исключительно в рамках регламентов.
Вам и документы первичные все покажут, и журналы исправно заполненные, и у кладовщика с бухгалтером уголок будет идти в конце месяца.
Для того, чтобы процессы действительно работали нужны инструменты, которые могли бы фиксировать их работу и все отклонения, исключающие пресловутый "человеческий фактор".
Процесс должен выполняться на все 100%, в противном случае - это черная дыра.
И что толку от прописанного регламента, если в процессе 5-10-...-99% транзакций вообще не понятно откуда и как [не]появились и мы ими не управляем?

Теперь, относительно содержания регламентов.
Здесь нужен уже принципиально другой подход к разработке регламентов, который должен учитывать движение ТМЦ, транспорта, тары, сопроводительных документов, денег, информации, работу приборов и инструментов, деятельность людей на каждом участке, необходимые и достаточные условия гарантированного протекания процесса, контрольные точки и контрольные значения.
В данном случае исполнители будут такими же объектами системы, как и инструменты.
Человек должен выполнить какую-то функцию, которую пока не смогли заменить железкой по причине отсутствия технологий и/или инструментов.
Другими словами, необходимо описать всю систему целиком со всеми объектами, внешней средой и субъектами управления и всеми связями таким образом, чтобы проходя через контрольную точку всё, и ТМЦ, и сопроводительные документы, и информация об этом означало одно и тоже.
Как только потоки движения объектов рассинхронизированы - это автоматически означает возможность для изменения протекания процесса от установленного порядка и уже не важно из-за чего, по злому умыслу, или по простоте наивной.
А регламентация банальной передачи ответственности от одного исполнителя другому ровным счетом ни о чем.
Ну и стиль изложения, это на мой взгляд уже последнее на что вообще стоит обращать внимание.

Если что-то не интересно или нечитаемо, считайте, что это уже не работает.

Полистайте ГОСТы или ТУ, или хотя бы вот это - то еще чтиво, но ведь работает
В конце концов, если бы я умел излагать мысли как Пушкин, Толстой, Достоевский или любой другой писатель/поэт, то наверное я бы не стал тратить свой талант на написание регламентов.
Кстати, тут выдержки из ГОСТ 2.105—95 по оформлению документов.
Очень интересны пп. 4.2.-4.4 - зачем изобретать велосипед?

...польза бизнесу ...

Для бизнеса полезным является работа процессов с минимальными транзакционными издержками.
В идеале, или как говорят физтехи, в пределе, мечта каждого владельца бизнеса - это чтобы бизнес летел на автопилоте и желательно вообще без его участия и всякого там персонала.
И не важно, регламентировано это по каким-то стандартам, или нет.
Идея не настолько утопична и не реализуема, как может показаться на первый взгляд.
Торговля на рынке forex автоматизирована более чем на 80%.
Сейчас уже вполне серьезно обсуждают автотранспорт без водителей.
IBM вводит в свой совет директоров с полноценным правом голоса компьютерную систему (к сожалению не могу найти ссылку).
Англичане с американцами планируют сделать самолет-матку, который будет по мере необходимости сам печатать разведчиков, штурмовиков, истребителей и т.п. с возможностью самолечения прямо в бою
Это называется перевести систему на самоуправление, а возможно это после опредмечивания и [само]отчуждения.
А это, действительно уже отдельная тема для целого цикла статей.

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

С Уважением,
К. Яцко

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений