Журнал о системах электронного документооборота (СЭД)
Workflow и управление бизнес-процессами

Гибкие процессы

  11 комментариев Добавить в закладки
Статья "Гибкие процессы"

Введение

Adaptive Case Management (ACM) – это концепция, альтернативная концепции BPM. Альтернативная – это значит, что решается та же самая задача эффективной организации бизнес-процессов, но другими средствами. Если совсем кратко, то идейное различие в подходах можно охарактеризовать следующим образом:

http://www.xpdl.org/nugen/p/adaptive-case-management/a/Graphic_BPM_core.jpg

BPM идет от структуры процесса, состава шагов, которые необходимо совершить, чтобы достигнуть цели. Данные могут возникать в ходе процесса, являясь полностью зависимыми от него.

 

 

http://www.xpdl.org/nugen/p/adaptive-case-management/a/Graphic_ACM_core.jpg

ACM идет от информации и бизнес-данных, возникающих в ходе работы и необходимых для того, чтобы считать результат достигнутым. Процессы возникают в контексте данных, а не наоборот [1].

 

 

Было уже достаточно и публикаций, и обсуждений [2], чтобы осветить основные идеи концепции ACM и не останавливаться на них здесь более подробно. Со своей стороны, мне бы сейчас хотелось поделиться некоторыми результатами, полученными при применении этих идей на практике.

1. Место ACM среди других технологий

Начнем с того, что BPM, Project Management (PM), ACM и ряд других управленческих технологий, применяются для управления деятельностью организаций.

Чтобы показать, каким образом ACM встраивается в практическую деятельность и каковы отличительные черты этой технологии именно в практическом применении, я воспользуюсь очень простой моделью деятельности, в которой выделены:

1) цель;

2) действие, направленное на достижение этой цели;

3) исполнитель, производящий это действие.

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

Далее, рассмотрим следующие свойства каждого элемента этой модели: повторяемость (как возможность многократного повторного использования одних и тех же описаний и моделей) и предсказуемость (как возможность предварительного планирования).

 

BPM

PM

ACM

Цель:

 

 

 

         Повторяемость

+

-

+

         Предсказуемость

+

-

+

Состав действий:

 

 

 

         Повторяемость

+

?

-

         Предсказуемость

+

+

-

Состав исполнителей:

 

 

 

         Повторяемость

+

?

?

         Предсказуемость

+

+

-

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

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

Когда меняются цели, меняются и требования к результату деятельности. Это значит, что статистика активностей пользователей, которую могла бы накапливать ACM-система, уже не сможет подсказывать, какие действия подходят к данной ситуации. Сравните, например, с проектным управлением, где непредсказуемость целей проекта компенсируется относительной предсказуемостью запланированных действий и исполнителей.

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

Далее, положим, что можно и от регламента отказаться, уповая лишь на инициативу работников умственного труда (knowledge workers). Но кто сможет показать хоть одну компанию численностью более десятка человек, где сотрудникам предоставлена полная свобода в целеполагании, выборе средств и методов работы? Конец доказательства.

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

Однако вернемся к «тотальной непредсказуемости», охватывающей, в том числе, цели бизнес-процессов. Какой должна быть технология управления в таких условиях? Ответ на этот вопрос, включающий обоснование, мне встретился в книге "Методология" (Новиков А.М., Новиков Д.А.) - для непредсказуемых целей наиболее адекватен проектный стиль управления. Но при этом потребуется приготовиться к перестройкам плана и изменению команды уже в ходе проекта.

Еще один ракурс, для полноты картины. С точки зрения проектного управления «тотальная непредсказуемость» - это признак проектов высокой сложности, для которых ключевыми вопросами являются вовсе не технологии автоматизации, а… лидерские качества и воля руководства. Впрочем, вопрос о проектах высокой сложности хорошо раскрыт в серии статей Сергея Чурюмова.

Но хватит моделей, перейдем, наконец, к практике.

2. Предельно конкретный пример

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

Казалось бы, при взгляде сверху, все просто. Но при погружении в детали начинаются «неприятности»:

●    Иногда решение можно принять после проверки одного-двух условий, и остальные уже не требуется проверять.

●    В разных случаях удобна разная последовательность проверки условий, жестко фиксировать последовательность нельзя.

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

В итоге, оптимальный алгоритм (и, соответственно, оптимальная схема данного этапа процесса) содержит массу ветвлений и с десяток различных состояний. И все это только для одного этапа процесса обработки заявки, рассчитанного на выполнение в течение нескольких минут реального времени!

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

Посмотрим, что изменится, если не пытаться описывать процесс, а попытаться описать результат, который требуется получить?

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

Условие 1

Условие 2

Условие 3

Условие 4

Заключение эксперта

Результат

1

Да

Да

Не важно

Не важно

Не важно

Подтвердить

2

Да

Нет

Да

Не важно

Не важно

Подтвердить

3

Да

Нет

Нет

Да

Не важно

Подтвердить.

4

Да

Нет

Нет

Нет

Нет

Отказать.

5

Нет

Не важно

Не важно

Не важно

Да

Подтвердить.

6

Нет

Не важно

Не важно

Не важно

Нет

Отказать.

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

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

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

Также здесь можно упомянуть еще один пример построенной по принципам ACM инструкции, опубликованный Анатолием Юмашевым, а также замечательный пост Максима Смирнова об одной реализации бизнес-процессов чек-листами. Хотя, на мой взгляд, контрольный список действий – это не единственная из возможных реализаций чек-листов, но описана она очень хорошо.

3. Взгляд со стороны нормативной документации

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

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

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

●    Влияние данных на содержание процесса. Когда малейшие изменения в данных или в требованиях к их обработке могут изменить процесс до неузнаваемости.

●    Наличие сквозных для всех процессов правил глобального действия – политик. Когда изменение одного правила ведет к изменению целого ряда (а то и всех) бизнес-процессов.

●    Вариативность реализации регламентов в различных подразделениях. Когда в филиалах или дочерних предприятиях холдинга одна и та же процедура адаптируется к местным условиям, что приводит к росту сложности внедрения изменений.

●    Объемность и регулярность обновлений. Когда динамичность и масштабы бизнеса приводят к тому, что даже ознакомление с изменениями всех подразделений – это нетривиальная задача, не говоря уж о том, чтобы поддержать изменения на уровне систем автоматизации.

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

●    Оценивать систему автоматизации - на предсказуемость каких компонент бизнес-процессов она рассчитывает.

●    Оценивать, насколько автоматизируемые бизнес-процессы  устойчивы к изменениям.

●    Дробить схемы процессов и стремиться к их переиспользованию. Чем меньше схема – тем меньше шансов, что она будет меняться при очередном обновлении регламентов.

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

●    Вычисления бизнес-правил должны выражаться в бизнес-значимых терминах, чтобы улучшить их переиспользование и сопровождаемость.

●    Точная спецификация бизнес-значимых параметров бизнес-процессов, которой должны удовлетворять реализации процессов в системе. Это упрощает процессы изменений.

●    Там где это оправдано, формулировать регламенты не в виде схем процессов, а в виде чек-листов.

4. Взгляд со стороны текущей деятельности сотрудников

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

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

1)     выявить шаблоны пользовательских действий и условия, при которых эти действия выполняются.

2)     научить системы автоматизации поддерживать эти шаблоны.

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

●    Инициатор и его место в оргструктуре предприятия. Дает ответ на вопрос: кому нужен шаблон?

●    Объект системы и его свойства, от которого инициируется задача. Отвечает на вопрос: в каком месте системы нужна инициация задачи по шаблону?

●    Структура задачи. Отвечает на вопрос: какие ситуации может охватить данный шаблон?

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

●    Структура задачи/Вложение – где была бы полезна кнопка на быстрый старт задачи?

●    Структура задачи/Вложение/Исполнители – можно ли сразу заполнить маршрут задачи?

●    Структура задачи/Вложение/Инициатор – кому показывать эту кнопку?

●    Инициатор/Структура задачи – кому мы можем помочь с устранением рутины?

●    Структура задачи/Инициатор – кому будет интересен данный шаблон?

Выводы, которые можно получать с помощью такого анализа:

●    Давать обоснованные предложения по развитию функционала и, особенно, пользовательского интерфейса

●    Выявлять заинтересованные в изменениях группы лиц

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

Заключение

В статье я попытался представить тему ACM с четырех различных углов зрения. Закономерно, что результаты, получаемые в каждом случае, внешне значительно отличаются друг от друга. Это говорит о том, что концепция ACM достаточно нетривиальна.

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

 



[1] Изображения взяты с сайта http://www.xpdl.org:

http://www.xpdl.org/nugen/p/adaptive-case-management/a/Graphic_BPM_core.jpg

http://www.xpdl.org/nugen/p/adaptive-case-management/a/Graphic_ACM_core.jpg

[2] См. например:

1.    http://www.slideshare.net/MxSmirnov/bpm-acm

2.    http://mainthing.ru/ru/item/401/

3.    http://doc.cnews.ru/news/top/index.shtml?2010/12/13/419781

4.    http://www.e-xecutive.ru/forum/forum54/topic9210/messages/

Ещё материалы автора
Похожие записи
Комментарии (11)
Максим Смирнов 18 сентября 2011 г. 16:18  

 

Евгений, очень хорошая статья, спасибо. Особенно мне понравился «Предельно конкретный пример» (раздел 2.) В целом, я считаю достаточно важным постоянно помнить о сложности и многоплановости бизнес-процессов и управлении ими, а потому и необходимости рассматривать их с разных точек зрения.

То, что принято называть дисциплиной BPM, на самом деле, взгляд на процессы всего лишь с одной точки зрения – с точки зрения проектировщика процессов. Взгляд на те же самые процессы с точки зрения исполнителя представляет собой обыкновенный список задач. С точки зрения руководителя – набор эскалаций и нарушений «соглашения об уровне сервиса» (положения об отделе, ожиданий топ менеджеров и т.п.). Есть еще business performance management, сосредоточенный на количественных характеристиках процессов. Далее подтягивается обеспечение ресурсами, workforce management и еще много-много чего. Для каждого взгляда и каждой точки зрения должны быть свои модели процессов: кому-то интересно, в какой последовательности осуществляются активности, кому-то обеспеченность задач требуемыми ресурсами, а кому-то – как вся эта суета влияет на объем выручки компании.

Сквозь шоры традиционного BPM-подхода видно далеко не все. Позволю себе шутливую реплику: «Это у нас не процессы слишком гибкие, а модели процессов, чересчур жесткие»

Евгений Кочуров 21 сентября 2011 г. 12:04  

Максим, спасибо за отзыв. Действительно, мои "4 угла зрения" выражают только одну точку зрения - проектировщика.

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

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

Евгений Кочуров 21 сентября 2011 г. 12:58  

Поясню последнюю фразу.

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

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

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

Анатолий Юмашев 04 октября 2011 г. 06:47  

 

 

Неее... пример вообще не в тему!

Евгений! Ё-моё! ))

Ты каким макаром определил способ получения сообщения как событие для процедуры? ))

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

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

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

Вот... и тут можно затронуть тему "неопределенности"... Это один из измирителей любой операции по процессам.

Скажем взять событие и процедуру "Заявление на отпуск" - тут определенность очень высокая и понятно что нужно сделать и что получить. Этап Исследования - не нужен.

А вот событие "Инцидент"... возможен этап Исследования, и не факт, что будут найдены те действия, которые приведут к устранению инцидента. А может быть будут найдены? Вот компьютер сломан, это инцидент. Может у него шнур отпал и инцидент будет решен за 10 минут? А может быть жесткий диск полетел? А там специальное шифрование, и на восстановление уйдет неделя? Так какой будет порядок действий? Шнур воткнуть? Или заказывать новые лицензии и установку шифрования на жесткий диск? С последующим ремонтом и т д?

А вот событие "Низкий уровень прибыли". В организации из 10000 человек. И каковы наши действия? Тут без исследования, определения гипотез, всестороннего обсуждения - ничего не сделаешь. Это тоже ACM, но чтобы довести такое событие до ожидаемого результата (а ожидаемым результатом такого события, если брать СМК ИСО 9000, является нормализация прибыли), уже нужно применять проектную технологию. ACM + PM = Love )

Вот как то так. Я не понял как средство доставки информации можно брать в качестве примера события для ACM.

Евгений Кочуров 04 октября 2011 г. 13:48  

Анатолий, я разве где-то сказал, что в статье привел пример инцидентной поддержки? Там на самом деле был описан прием заявок на регистрацию (не скажу куда ;) ).

Твои примеры работы службы поддержки и реакции на события типа снижения прибыли принимаю.

Я не понял как средство доставки информации можно брать в качестве примера события для ACM.

Что тут имеется ввиду?

Анатолий Юмашев 04 октября 2011 г. 17:42  

Так я про то и говорю... давай рассматривать какие-то более реальные примеры.

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

И привел пример, что заявку (не скажешь куда) я вам и по телефону могу дать, и по почте, и по аське и т. д. Разве от этого состав действий исполнителя сильно меняется? Да хоть голубем прилетела! Ему главное информацию увидеть и пошел делать.

И мне этот пример очень не нравится, т.к. он не дает картины и не расскрывает проблематику предмета.

Давай уйдем в более конкретную предметную область. Что за заявка? Куда?

А как она поступила - это второстепенно и не интересно. 

И для примера предложил взять Инцидент. Он же может поступить через сайт? И это более реальная процедура, более интересная.

Но! Этот инцидент может поступить не только как заявка через сайт, а еще кучей других способов.

На способы предлагаю закрыть глаза. Их может быть очень много.

Предлагаю рассматривать те события и те процедуры, которые находятся за "способами доставки". Они более реальны и более интересны.

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

И ладно вам комерсантам проще )) у вас там способов доставки то ) телефон, мыло да сайт )

А нам чиновникам? У нас тут и ДИКС, и СМЭВ и всякие там АРМы с криптографией. И все это способы доставки. Если мы их все описывать начнем - беда прям ) Да и толку от этого нет.

Евгений Кочуров 04 октября 2011 г. 18:28  

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

И мне этот пример очень не нравится, т.к. он не дает картины и не расскрывает проблематику предмета.

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

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

Анатолий Юмашев 04 октября 2011 г. 18:39  

Понято.

Тогда еще один вопрос... как ты относишься к идеи и попытке декомпозиции процессов?

С целью получения дерева процессов, где на верхнем уровне процесс под общим названием типа "Деятельность в области ИТ" или "Машиностроение" или "Предоставление гос.услуг"

А далее этот процесс разбивается на подпроцессы и процедуры... (эту идею упер у SAP & BusinesStudio)

Мне вот интересно, как ты определил что это процедура нижнего уровня, и какой процесс для нее будет вышестоящим в таком случае? )

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

Евгений Кочуров 04 октября 2011 г. 18:52  

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

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

Анатолий Юмашев 04 октября 2011 г. 19:08  

Нууу ёмое )) так мы далеко не уедем ) моя селезенка чует в этих положениях ошибку. И либо ошибаюсь я, либо ты. Но объяснить того что хочет моя селезенка, без конкретного примера я не могу )) Точнее могу, но получится очень много слов, перегрев сначала моего, а потом вашего мозга ) Потому во избежании лишних кубометров дыма из наших голов, подождем статьи с более конкретными примерами )

Анатолий Юмашев 04 октября 2011 г. 19:29  
моя селезенка чует в этих положениях ошибку

Громко сказано )) и грубо )) статья в целом - есть гут и вери гут. В голове новый уровень порядка навела.
Но где-то и что-то не то. Либо в статье, либо у меня в голове. А докопаться не могу, т.к. хоть и разобран конкретный пример, да все равно он слишком секретный и абстрактный. Зацепиться не за что и вытянуть ошибку ) из статьи либо из моей головы ))
Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев