Обсуждение

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

Расследование показало, что пока он не столько говорит, сколько попугайничает фразы. Скажем, подходит к предмету, по поводу которого вчера взрослые настойчиво произносили "что это!" и точно так же спрашивает, "что это?". Ибо на первом этапе обучения его заставляли для того, чтобы получить предмет, повторять за взрослым его название. Ну, дальше он начал повторять все, что слышит -- в том числе обрывки фраз, которые в этот момент произносят взрослые. Очень смешно, но непродуктивно. Скажем, показывает на высоко лежащий диск и говорит "дай!", ему говоришь, "что это?" -- он повторяет "что это?". Другое дело, что повторяет все отчетливей и отчетливей, и уже не нужно напрягаться, чтобы понять его "эхо". Нормально, все через это проходят, только на пару лет раньше. А сам (не повторяя) говорит преимущественно глаголами повелительного наклонения.

Невероятный, говорите? Фантастический?:) Хе-хе:)

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

можно взглянуть на схему двухуровневой рефлексии?

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

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

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

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

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

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

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

Попробую по-другому объяснить. У меня есть такое правило: никогда не делай автоматизацию несуществующего бизнес-процесса. Т.е., приходит клиент, говорит: у меня тут есть бардак в бизнес-процессе (или я запускаю новый процесс/новый бизнес), давай напишем для него систему. Клиент в таких ситуациях чаще всего идет далеко-далеко (или я максимально страхуюсь от ответственности формулировками ТЗ, но все равно после окончания проекта чувствую себя некомфортно, потому что система работать не будет). Если процесс плохо формализован, то написать под него жесткую систему нельзя – он изменится, пока система будет создаваться. Поэтому стандартный ответ такому клиенту – сначала давай сделаем в Excel’е, отработаем процесс, а потом уже будем что-то содержательное творить. Именно поэтому меня так заинтересовали ваши слова про проектирование. Если бы можно было посадить вместе, в одной комнате, с одним и тем же инструментарием, оргпроектировщиков и проектировщиков информационной системы, то можно было бы делать систему одновременно с изменениями в бизнес-процессах.

Да, конечно, модель бизнес-процесса должна создаваться прямо в софте (моделлере) -- и обсуждаться всеми заинтересованными лицами, причем создавать ее должен не айтишник, а оргпроектировщик (так же, как в Ворде тексты пишет писатель, а не айтишник ;). Система исполнения бизнес-процессов каким-то образом должна использовать модель. Тогда любое изменение не будет приводить к переписыванию кодов системы. А у вас текст написан так, как будто вы бизнес-процесс прямо таки кодируете на каком-то языке, и перед тем как кодировать, отрабатываете его на exel. В том-то и фишка, чтобы не кодировать, а описывать модель. Впрочем, это сегодня -- общее место. Единственное, что отличает мои рассуждения от мейнстрима, так это предложение использовать для моделирования язык представления знаний общего вида, а не BPML или BPEL с какими-то языками представления оргструктуры из набора стандартов WfMC.

Да я и не призываю к тому, чтобы оргмоделированием занимались айтишники! Я с самого начала написал: "менеджмент должен заниматься проектированием организации в тех же терминах, в том же инструментарии, в том же процессе, в которых ИТ проектирует информационную систему". Потом менеджмент мы заменили на оргпроектировщиков, но айтишникам я эту функцию не приписывал! :) Какова область применимости той схемы, о которой вы говорите ("система исполнения бизнес-процессов каким-то образом должна использовать модель" и далее по тексту)? По размеру организации, по сложности системы, еще по каким-то критериям? В какой мере это применимо, например, к малому бизнесу? ЗЫ. Выложил ссылку на этот пост в it_outsourcing. Думаю, это будет полезно почитать интересующимся - от вас можно (и нужно) многому научиться.

Сначала, как правильно говорит vinopivets, напишем для себя русским языком до конца, и только потом переведем на общемодельный отчуждаемый язык, а то иначе крышу снесет от попытки сразу делать сущее на языке-интерпретаторе:)) А вот потом что получилось в нормальном русском языке (да-да! с помощью экселя и ворда в то числе, а также пауэр поинта:))) Обязательно проинтерпретируем в отчуждабельный модельный вид:))

Правильно сначала не писать русским языком, а рисовать схемы. А тексты на русском языке -- проговаривать.

ОК. Да, так и делается, если по правде... Схема, обсуждение, перевод в модельный язык

Именно. Потому как "просто русского языка" не бывает -- это всегда развертка схемы.