Обсуждение

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

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

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

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

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

ага, для тебя "организационная" - ответ на вопрос "модель чего?", а для меня - "модель где?"

Ну я например делаю так: Модель компании (компоненты) 1. Онтологическая модель (базовые понятия и классификаторы) 2. Структурная модель (иерархия управления: оргструктура, штатная расстановка, география, структура ИТ, структура производства и т.п.) 3. Процессная модель управления (процессы управления деятельностью, их часто называют бизнес-процессы) 4. Технологическая процессная модель (технологические процессы) Модели 3, 4 могут быть статическими (структура) или динамическими (исполнение). Есть идея нарисовать их всех на 1 листе в формате матрицы Захмана. Но там надо здорово попыхтеть, а времени нет. Да и руководство компаний пока еще не готово к восприятию таких моделей. Пробовал на Ростелекоме - получил нулевую реакцию.

То есть для тебя это "организационная модель всего"? :) Круто. Никогда так не думал.

Ну, нам Захман представляется чересчур навороченным для наших целей: он уже привел к появлению дюжины самых разных стандартов для описания всего этого хозяйства -- и вся эта "корпоративная архитектура" абсолютно неподъемна. Вы в вашем наборе моделей идете от системного подхода (1-мета, 2-структуры, 3-процессы, 4-материал), так? Это значит, что чертежи (т.е. модель) продукции у вас попадают в технологические процессы? Но ведь они не процессы! И как вы технологические процессы отличаете от управленческих? Или это как раз процессная модель продукции? Руководство компании вполне готово к восприятию моделей, если им объяснять долго и много про модель как таковую. А объяснение модели идет через объяснение понятия учета. Остальное объяснять уже просто. Мы как раз тренируемся все это объяснять руководству. Пока они про "модельность" и "учетность" не поймут в общем случае, никакие модели не воспринимаются всерьез. Затем воспринимаются.

модель всего, что нужно учитывать в организации. что тут неожиданного?

>> Ну, нам Захман представляется чересчур навороченным для наших целей: он уже привел к появлению дюжины самых разных стандартов для описания всего этого хозяйства -- и вся эта "корпоративная архитектура" абсолютно неподъемна. Согласен и не предлагаю слепо заполнять матрицу Захмана (как это делают например разработчики системы CASEWISE).Но сама идея с выделением аспектов (перспектив) моделирования мне нравится. Работа над адаптацией захмановской модели еще далека от окончания и что-то конкретное говорить рано, скажу только что вижу следующие аспекты (в приложении к компании): ..........................................Цели.......Процессы.....Структуры......Люди.........Динамика........Онтология ........................................(Мотивы)...(.............)....(География)...(Функции)....(..............)....(Классификаторы) Стратегический уровень Концептуальный уровень Функциональный уровень Уровень компонент Уровень приложений Уровень данных >> Вы в вашем наборе моделей идете от системного подхода (1-мета, 2-структуры, 3-процессы, 4-материал), так? Это значит, что чертежи (т.е. модель) продукции у вас попадают в технологические процессы? Но ведь они не процессы! И как вы технологические процессы отличаете от управленческих? Или это как раз процессная модель продукции? Чертежи конечно вместе с техпроцессами, а где еще? На тему отличия управленческих и технологических процессов пару лет назад на форуме cfin.ru были серьезные ругачки. Но закончилось все ничем - каждый остался при своих. Из чего лично я сделал такой вывод: Граница между двумя видами процессов нечеткая и определяется соглашением команды моделирующей процессы и руководства предприятия. PS. Как раз сегодня один из топ-менеджеров нашей компании задал долгожданный вопрос: "А где Я на вашей карте процессов верхнего уровня?" На что получил: "На этом уровне вас нет". Посмотрим теперь развитие событий. :-)))

У вас очень абстрактное (программистское? ;) видение организации. Мы пошли другим путем, и выделяем в организации Нормы, Работы, Ресурсы и Показатели (а вот с "технологическими процессами, чертежами, настройками и кодами внутри турбин, реакторов и компьютеров" пока не определились, куда их засунуть). Тем самым даже оргфункциональная модель у нас получается в пересечении Норм (функции берутся из процессов, а описания процессов -- это Нормы) и Ресурсов. У нас вчера на семинаре как раз один из руководителей настаивал на автономности Норм (процессных в данном случае) от ресурсов -- т.е. радостно отказывался от построения классической оргфункциональной модели, как ненужного для него среза -- а именно эта модель требовалась для местного оргмоделлера Business Studio). Что показало нам правильность избранного пути :) Для нас был бы странен вопрос про "где я на карте процессов" -- люди (в том числе руководители) у нас в Ресурсах, а вопрос этого вашего топ-менеджера для нас бы звучал "а где я в вашей системе норм на верхнем уровне" и требовал бы совсем других ответов :) Поглядеть на наши наработки (увы, не все и сильно отстающие, как всегда, от достигнутого фронтира) можно на http://praxos.ru. А моделлер мы решили делать свой, колупаем что-то на смоллтоке.

>> У вас очень абстрактное (программистское? ;) видение организации. Не буду отрицать. Все таки - я инженер и программист с солидным стажем, переквалифицировавшийся ныне в управдомы, то есть тьфу - в бизнес-аналитики :) На мой взгляд, в данном случае не стоит придавать негативный оттенок словам "Абстрактное" и "Программисткое". Определенный уровень абстракции необходим для системного обобщения, а навык структурного программирования (алгоритмизации) очень ценен при разработке алгоритмов исполнения процессов. Я как-то предложил рассматривать работу с системой управления организацией как набор (комплекс) состоящий из 3х взаимодействующих процессов: 1. Разработка. 2. Исполнение. 3. Управление изменениями. Но аудитория (сотрудники компании) были не готовы и пришлось работать в устоявшейся парадигме. >> Мы пошли другим путем, и выделяем в организации Нормы, Работы, Ресурсы и Показатели (а вот с "технологическими процессами, чертежами, настройками и кодами внутри турбин, реакторов и компьютеров" пока не определились, куда их засунуть). Нууу, говоря о своей модели я конечно немного упростил ситуацию. И не упомянул о наличии еще пары-тройки измерений. Благодаря которым красивая матрица "а-ля Захман" превращается в нечто трех-пятимерное из параллельного пространства. :) Если кроме шуток, то ваши Показатели вписываются в "Онтологию", а Ресурсы - в "Структуру", Нормы прекрасно себя чувствуют в "Процессах", а Работы - в "Функциях". Дьвол прячется как всегда в деталях - и выскочит когда мы начнем рисовать связи между ячейками матрицы. Но никто ведь и не говорил, что будет легко :) >> А моделлер мы решили делать свой, колупаем что-то на смоллтоке. Вы не одиноки в своих устремлениях. Мог бы назвать еще несколько групп, которые пытаются работать в этом направлении. Кроме меня - так как нахожусь еше на стадии разработки концепции. Упоминание смолтока вытащило историческую параллель - была когда-то такая группа Rational, которая придумала объектно-ориентированное программирование. Затем часть из них создала компанию Rational Software и выпустила инструмент моделирования Rational Rose. Копаясь в кодах Rose, я нашел артефакты, свидетельствующие о том что изначально продукт разрабатывался на Smalltalk. Что касается Business Studio - по моему скромному мнению, это просто очень хорошая команда маркетологов. Ничего принципиально нового они и не стремятся внести, а с концептуальной точки зрения дрейфуют по воле волн. Я слежу за ними с момента первой пробы пера, когда они выставили свою концепцию на всеобщее обозрение и до сего времени. Изначально система строилась для реализации "Восьми-процессной модели БКГ", потом там оставил свой след В.Кондратьев ... а сейчас каждая группа пытается ваять что-то свое кондовое.

У нас все рассуждения про онтологию и моделирование остаются, конечно -- абстракции никуда не уходят. Нас интересует сразу предметный уровень, в котором описывается что-то на языке уже организации (а не чего угодно "системного" -- так, функции, процессы, структура может быть у чего угодно, хоть у мамонта как системы. А вот ресурсы, нормы, работы и показатели -- это уже специфические слова, это уровень ниже "онтологии". А "онтология" уходит в meta, как и учеты). Вы правы, процессы (которые бизнес-процессы) у нас в нормах, а разные "структуры" -- в ресурсах. Но вот работы -- это не функции, у нас там экземпляры процессов, над которыми строятся графики их исполнения. Что же касается "функций", то с ними нужно отдельное разбирательство (там есть "функции" как "предназначение", и есть еще функции ресурсов как "компетенции" -- это разное). Можно много говорить о наших онтологических предложениях, что мы, собственно постоянно и делаем, когда ходим по клиентам :) Каждая наша онтологическая новация решает конкретную традиционную организационную проблему. Мы стараемся решать онтологические задачки, внутренний язык "про онтологии" существенно отличается от того, на котором мы разговариваем с сотрудниками консультируемых предприятий. Насчет Смоллтока, так это неслучайный выбор, конечно. Там много больше интересных историй, чем история монструозной проработки Rational Rose. Я много писал об этом в своем блоге полгода назад. Business Studio -- это моделлер, а не метамоделлер. Разработка ОргМастера нами ценится много выше, там в основе полноценная семантическая сеть лежит и поддерживаются полноценные n-арные отношения (мы проверяли ;)