Страница 2 из 3 ПерваяПервая 123 ПоследняяПоследняя
Показано с 31 по 60 из 63
  1. #31

    По умолчанию

    Дмитрий!
    Вы меня извините, но Юлия начала тему с вопроса ТОЛЬКО ОБ АНАЛИЗЕ ОРГСТРУКТУРЫ.
    Ну вот такая наша Юлия
    Юлии, как в прочем и любому, кто пытается придумать, что-либо новое (именно придумать, а не использовать готовую методику) очень важны мнения и отзывы. Вот она и выложила в впопыхах условия, оторванные от программы, которые без дополнительных объяснений понять очень сложно. Но ничего, если будет интерес, я думаю, она всё подробно расскажет.


    Подобную задачу я решал в 2003-2004 г. и начиналось решение не с оргструктуры, а с целей, затем процессов, а уж только потом - оргструктура. Об этом и матрица Захмана говорит, а модель Захмана - это 20% из всех методик мира (больше всех).
    Я правильно понял, что Вы считаете, что необходимо сначала ставить цели, затем строить бизнес процессы, которые будут эти цели достигать, а лишь затем формировать оргструктуру? Проблема в том, что подобная методика с легкостью применяется для новых или открывающихся предприятий. А программный продукт приобретают уже предприятия со сформированными целями, какой-никакой построенной оргструктурой, и уже существующими бизнес процессами (пускай и нерегламентированными). Не могут же они в один момент упразднить все должности и начать «с нуля». Поэтому и приходится идти от обратного – строить оргструктуру, затем проверять какие функции эти должности выполняют в бизнес-процессах и давать рекомендации по изменению оргструктуры и/или процессов. Возможно, есть и другой способ, но я его пока что не знаю.

  2. #32

    По умолчанию

    Вы правы в том, что клиенты голосуют ногами - вот когда ваша фирма догонит по обороту хотя бы 1С, тогда и поговорим.
    Догонять лучше не по обороту, а по прибыли

    Но и в целом с вашей формулировкой я не согласен. Успешный проект – это тот проект, который кормит своих создателей и приносит достаточно прибыли для дальнейшего развития. Когда проект достигает успешности уровня 1С, тогда видимо необходимость в подобных разговорах с Болдиным у них уже пропадает ;)

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

    P.S. А вообще, Болдин, почему Вы так конфликтно разговариваете? «когда дорастёте, тогда поговорим и прочее» Проблемы в работе или в личной жизни? Может кризис среднего возраста? Иль характер просто скверный?

  3. #33
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Zerg
    1. Не хватит, а если хватит своё писать будут. Область пусть система моделирования бизнес-процессов.
    2. Это не универсальное ПО подходящее всем, это лишь хороший инструмент. Например многопользовательский доступ в данном инструменте, нельзя сказать отсутствует, но близко к этому.
    Я это все к тому, что создание таких ПО близко к утопии на мой взгляд.
    Ведь даже 2 компании конкурента на конкретном рынке покупая одну и ту же конфигурацию 1С дорабатывают её по разному. А все потому, что 2 одинаковых бизнес-процесса в организациях не найти - как двух одинаковых отпечатка пальцев.
    Не обижайтесь, но вы находитесь в плену распространенных заблуждений:
    - Моделирование бизнес-процессов это рисование картинок со стрелочками. На самом деле, в моделировании наибольшую часть работы составляют: сбор информации, формирование веера приемлемых сценариев выполнения процесса, обоснование выбора оптимального сценария, выбор формы представления и его согласование с участниками процесса... и так далее. На фоне всего этого рисование диаграмм - детская задачка.
    - Для моделирования бизнес-процессов компании необходим многопользовательский доступ к инструменту моделирования. Многопользовательский доступ нужен к результатам моделирования, но не к процессу разработки, а это легко достигается простыми средствами. Например, за счет интегрированности MS Visio в MS Office, диаграммы Visio можно публиковать в Интернет прямо из Visio. Не говоря уже о том, что их можно вставлять копи-пастом в MS Word или MS PowerPoint ... как мы чаще всего и делаем.
    - В компании не найти двух одинаковых бизнес-процессов, они как отпечатки пальцев. На самом деле, подавляющее большинство БП - типовые. Уникальными являются процессы либо создающие ценность для покупателя либо ноу-хау позволяющие снизить затраты ... да и то они пестрят типовыми вставками.
    Поэтому часто за утверждениями об уникальности наших процессов стоит элементарное желание пристроить хорошего человека на непыльную должность (ну там методолог бухгалтерского учета или что-то наподобие).

    Я мог бы распространяться на эту тему долго, но времени немного, да и смысла не вижу.
    Последний раз редактировалось А.Б.; 10.09.2009 в 18:38.

  4. #34
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    Догонять лучше не по обороту, а по прибыли Но и в целом с вашей формулировкой я не согласен. Успешный проект – это тот проект, который кормит своих создателей и приносит достаточно прибыли для дальнейшего развития. Когда проект достигает успешности уровня 1С, тогда видимо необходимость в подобных разговорах с Болдиным у них уже пропадает
    Наверное вам лучше знать: вы предприниматели - я наемник. Квалифицированный и неплохо оплачиваемый, но наемник ... защищающий интересы той компании, в которой работаю. Поэтому, кстати, успешный для вас проект не обязательно будет успешным с моей точки зрения.
    Для самого загадка, но "необходимость в подобных разговорах" почему-то не отпадает ... даже у проектов с успешностью в разы превышающей 1С.
    Цитата Сообщение от Петров Дмитрий
    Со мной что-то делать или с клиентами?
    С вами с вами
    Цитата Сообщение от Петров Дмитрий
    Я считаю так – потребность в программе возникает в том случае, если программа удовлетворяет потребности клиента.
    Распространенная ошибка - потребность в покупке чего-то обусловлена в осноном появлением свободных денежных средств.
    Цитата Сообщение от Петров Дмитрий
    P.S. А вообще, Болдин, почему Вы так конфликтно разговариваете? «когда дорастёте, тогда поговорим и прочее» Проблемы в работе или в личной жизни? Может кризис среднего возраста? Иль характер просто скверный?
    Еще одна распространенная ошибка: то что вы видите как "конфликтность" есть стремление перевести дискуссию из статуса трепа в статус поиска решения. Без обострения результата не получите - так и будете трепаться ни о чем.
    Ну и характер - тоже не сахар. Отрицать не буду. :-Р

  5. #35
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    Ну вот такая наша Юлия
    Ну, за Юлю Вы не волнуйтесь, с ней мы уже договорились.
    Я правильно понял, что Вы считаете, что необходимо сначала ставить цели, затем строить бизнес процессы, которые будут эти цели достигать, а лишь затем формировать оргструктуру? Проблема в том, что подобная методика с легкостью применяется для новых или открывающихся предприятий. А программный продукт приобретают уже предприятия со сформированными целями, какой-никакой построенной оргструктурой, и уже существующими бизнес процессами (пускай и нерегламентированными). Не могут же они в один момент упразднить все должности и начать «с нуля».
    Если начинать с "чистого листа", то Вы поняли меня правильно.
    Если начинать проект в работающей организации, то Вы тоже правильно поняли, но ....
    Если Вы анализировали цели работающей организации и пытались выяснить: "Кто отвечает за достижение цели N?" - Какой ответ Вы получали?
    Я думаю: "А кто её знает" или что-то покрепче. Это очень непростая задача, увязывать действующие цели и ответственность за них (причем это должна быть не BSC на бумажке). Мне это удается не более чем в 30% проектов. В остальных случаях - топы просто отпихиваю ответственность, а внешний консультант не может их заставить, только "внутренняя палка гендира или собственника".

    Поэтому и приходится идти от обратного – строить оргструктуру, затем проверять какие функции эти должности выполняют в бизнес-процессах и давать рекомендации по изменению оргструктуры и/или процессов. Возможно, есть и другой способ, но я его пока что не знаю.
    Цитата из Положения о департаменте:"Участие в обеспечении организации взаимодействия между...." - как Вы это проанализируете и в какой бизнес-процесс отнесете?
    Цитата подлинная.

    + к Болдину:
    4. Иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных.

    Автор - Гради Буч. (Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2008 г), которого я рекомендую прочитать всем разработчикам.
    Типов процессов действительно немного ( я насчитал пока 4).
    С уважением Виталий.

  6. #36

    По умолчанию

    то что вы видите как "конфликтность" есть стремление перевести дискуссию из статуса трепа в статус поиска решения. Без обострения результата не получите - так и будете трепаться ни о чем.

    Я тоже за поиск решения. Каким Вы его видите в данной ситуации применимо к построении оргструктуры? Давайте всё-таки предположим, что необходимость в построении оргструктуры в программном продукте есть, пускай даже как вспомогательного элемента к другим функциям программы. Я не прошу изложить весь алгоритм, естественно это большая работа, но хотя бы основные положения того, что Вам, как потенциальному пользователю хотелось бы видеть в программном продукте.
    Если Вы анализировали цели работающей организации и пытались выяснить: "Кто отвечает за достижение цели N?" - Какой ответ Вы получали?
    Я думаю: "А кто её знает"
    или что-то покрепче.
    Согласен, цели, безусловно, важны. Вопрос лишь состоит в резонности привязки элементов оргструктуры и бизнес процессов к целям в программном продукте с учётом того, что цели (а особенно декомпозированные на более мелкие задачи) могут менять динамически и довольно часто, в то время как бизнес процессы и оргструктура подвержены изменениям намного реже. К сожалению, реализуя те или иные функции в программном продукте, приходится сознательно идти на упрощения и компромиссы между сложностью и удобством работы с программой.

    Цитата из Положения о департаменте:"Участие в обеспечении организации взаимодействия между...." - как Вы это проанализируете и в какой бизнес-процесс отнесете?

    Я могу быть неправ, но мне кажется, что стоит избегать написания ничего не значащих фраз в положения и ДИ. Если за фразой «Участие в обеспечении организации взаимодействия между....» не стоит каких-либо конкретных функций, за которые отвечает конкретный персонал, то и писать её не стоит.
    Автор - Гради Буч. (Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2008 г), которого я рекомендую прочитать всем разработчикам.
    Спасибо, постараюсь ознакомиться.

  7. #37
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

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

  8. #38
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    Я тоже за поиск решения. Каким Вы его видите в данной ситуации применимо к построении оргструктуры?
    Будучи патологически добрым, не буду вас отправлять в поиск на форуме - скажу сразу:
    Движущие силы, формирующие систему управления организацией:
    1. Процессы
    2. Иерархия
    3. Корпоративная культура
    4. Стейкхолдеры
    5. Лидерство
    Эти силы, взаимодействуя друг с другом, собственно и создают некую схему взаимодействия людей в при осуществлении некоей деятельности - то есть Организацию. Организационная структура представляет собой моментальный снимок установившегося на данный момент равновесия 5 сил. Пытаясь нарисовать оргструктуру исходя из понимания какой-то одной силы (как например действуют консультанты - ВГЕ - без обид да?) мы с вами неизбежно создадим уродца - эдакого виртуального компьютерного монстра. При этом, реальное взаимодействие будет происходить по непонятным для нас правилам. Чисто по понятиям.

    PS. Не ищите подтверждения или опровержения написанного выше в книжках - своего я еще не публиковал и аналогов не встречал. Нету времени на оформление хоть в каком-то виде. Потом как-нибудь ...
    Последний раз редактировалось А.Б.; 10.09.2009 в 19:22.

  9. #39
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    Я не прошу изложить весь алгоритм, естественно это большая работа, но хотя бы основные положения того, что Вам, как потенциальному пользователю хотелось бы видеть в программном продукте.
    Как у "потенциального разработчика аналогичного продукта" у меня есть SRS на 200 с лишним страниц.
    Согласен, цели, безусловно, важны. Вопрос лишь состоит в резонности привязки элементов оргструктуры и бизнес процессов к целям в программном продукте с учётом того, что цели (а особенно декомпозированные на более мелкие задачи) могут менять динамически и довольно часто, в то время как бизнес процессы и оргструктура подвержены изменениям намного реже.
    Давайте разделять две сущности: цель и набор показателей в числовом выражении, плановые значения которых могут меняться каждый месяц.
    Изменение цели - требует изменения процесса и, следовательно, изменения оргструктуры, ресурсов, технологий и т.д.
    Я могу быть неправ, но мне кажется, что стоит избегать написания ничего не значащих фраз в положения и ДИ. Если за фразой «Участие в обеспечении организации взаимодействия между....» не стоит каких-либо конкретных функций, за которые отвечает конкретный персонал, то и писать её не стоит.
    Вы меня не поняли, или я выразился нечетко. Эта фраза УЖЕ НАПИСАНА и Ваш продукт должен будет анализировать этот бред.
    Хотя я специально написал: "Цитата подлинная".
    С уважением Виталий.

  10. #40

    По умолчанию

    Будучи патологически добрым, не буду вас отправлять в поиск на форуме - скажу сразу:
    Движущие силы, формирующие систему управления организацией:
    1. Процессы
    2. Иерархия
    3. Корпоративная культура
    4. Стейкхолдеры
    5. Лидерство
    Вы очень добры, Александр, но где-то очень-очень глубоко внутри Процессы и иерархию мы можем задать в программном продукте, а вот, например, «лидерство», ну никак. Хотя может, я просто не понимаю как.
    Как у "потенциального разработчика аналогичного продукта" у меня есть SRS на 200 с лишним страниц.

    Хорошо Вам. Довольно интересно будет посмотреть на реализацию готового программного продукта.
    Вы меня не поняли, или я выразился нечетко. Эта фраза УЖЕ НАПИСАНА и Ваш продукт должен будет анализировать этот бред.
    А так, к сожалению, не выйдет Пока что нет таких технологий, чтобы анализировать произвольно написанные документы на «бредовость». Можно лишь наоборот, генерировать эти документы автоматом, вставляя информацию из процессов и оргструктуры. Тогда подобных ничего не значащих фраз не будет изначально. Но даже при этом ответственность за правильность заполнения функций в процессах будет целиком и полностью лежать на человеке. Проверять и анализировать мы можем лишь простые вещи, такие, как кол-во сотрудников занимающих должность, кол-во подчиненных сотрудников, кол-во выполняемых функций на 1 должность и т.д. и уж на основе этой информации пытаться давать рекомендации из разряда тех, что я привёл выше.

  11. #41
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Петров Дмитрий

    Хорошо Вам. Довольно интересно будет посмотреть на реализацию готового программного продукта.
    Нет, мне плохо! В 2004 инвестор не нашел $200К на написание кода, осталась SRS на 1 (один) модуль "Консультант" из 4-х запланированных.

    А так, к сожалению, не выйдет Пока что нет таких технологий, чтобы анализировать произвольно написанные документы на «бредовость». Можно лишь наоборот, генерировать эти документы автоматом, вставляя информацию из процессов и оргструктуры.
    Опять я не понимаю Вас....
    Петров писал:
    программный продукт приобретают уже предприятия со сформированными целями, какой-никакой построенной оргструктурой, и уже существующими бизнес процессами (пускай и нерегламентированными). Не могут же они в один момент упразднить все должности и начать «с нуля». Поэтому и приходится идти от обратного – строить оргструктуру, затем проверять какие функции эти должности выполняют в бизнес-процессах и давать рекомендации по изменению оргструктуры и/или процессов.
    Вот в этой "какой-никакой построенной оргструктуре" Вы и встречаете такую дикую фразу. Что делать????????
    С уважением Виталий.

  12. #42

    По умолчанию

    Под «какой-никакой оргструктурой» я подразумевал, что определены должности, сформированы подразделения, есть штатное расписание, возможно, определена административная подчиненность. Вот их и можно проанализировать, и то, только после того, как кто-то введёт эти данные в программу. Документы, написанные в вольной форме в Ворде программа естественно анализировать не может по техническим причинам.
    Зато построив оргструктуру в виде дерева, назначив ответственность за бизнес процессы и выполняемые функции, назначив сотрудников на соответствующие должности такие документы как ДИ и положения о подразделениях можно на 70-80% генерировать полностью автоматически, перенеся подчиненность из дерева оргструктуры, ответственность из бизнес процессов, а функции из функций должностей, работающих в подразделении, используемые документы из бизнес-процессов, оттуда же взаимодействия с другими должностями по процессам и т.д. и т.п.

  13. #43
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Существуют ли общие правила и рекомендации, применимые к построению административных организационных структур и возможна ли их автоматизация?
    1.Да.
    2.Нет.


    1.По поводу общих правил.
    Помимо модели Захмана есть еще близкое по смыслу высказывание Хезера Остерлоха, по памяти: Структура подчинена процессам, процессы подчинены стратегии.


    2.По поводу возможностей автоматизации.
    Кажется, Голдратту принадлежит высказывание, по памяти: главные параметры, определяющие деятельность организации, неизвестны и количественно неопределимы.
    Следующее высказывание точно от Голдратта: «Организация – совокупность принятых кем-то ранее решений».
    Решения по оргструктуре – важные решения для организации.
    Они, во-первых, носят творческий характер, и, во-вторых, определяются сшибкой разнонаправленных движущих сил, о котрых писал Болдин.
    Решения по оргструктуре – результат: 1)творческой 2)коллективной работы.
    Формализовать выработку таких решений, уверен, нереально.
    А делать мастырку, автоматизирующие указанные ниже в цитатах функции – на мой взгляд, не имеет смысла.
    Если продиагностировать «узкие места» организации, то, полагаю, проблемы с указанным в цитатах функционалом окажутся далеко в хвосте проблем организации.
    Проверять и анализировать мы можем лишь простые вещи, такие, как кол-во сотрудников занимающих должность, кол-во подчиненных сотрудников, кол-во выполняемых функций на 1 должность и т.д. и уж на основе этой информации пытаться давать рекомендации из разряда тех, что я привёл выше.
    Зато построив оргструктуру в виде дерева, назначив ответственность за бизнес процессы и выполняемые функции, назначив сотрудников на соответствующие должности такие документы как ДИ и положения о подразделениях можно на 70-80% генерировать полностью автоматически, перенеся подчиненность из дерева оргструктуры, ответственность из бизнес процессов, а функции из функций должностей, работающих в подразделении, используемые документы из бизнес-процессов, оттуда же взаимодействия с другими должностями по процессам и т.д. и т.п.


  14. #44
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

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

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

  15. #45
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Перестань. Первая строка в матрице Захмана - НАМЕРЕНИЯ.
    См. хотя бы здесь: http://www.osp.ru/os/2001/12/180711/

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

    Ну ты силен.
    Нет чтобы добарывать Дмитрия, так одновременно начинаешь бороться даже с соратниками

  16. #46
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    Ну ты силен.
    А вы тут чо, типа боретесь? А чего сразу не сказали?
    Я бы и не парился... Армрестлинга и на работе хватает - лично мне на форуме интересно послушать мнения... в том числе по своим слабооформившимся мыслям.

  17. #47

    По умолчанию

    Нет чтобы добарывать Дмитрия, так одновременно начинаешь бороться даже с соратниками
    Так а зачем меня добарывать, я ведь ни с кем не спорю и ничего против Захмана, Остерлоха и Голдрата не имею Только констатирую, что возможно реализовать в программном продукте, а что нет (по моему мнению). Вы утверждаете, что подобная функциональность не нужна, и я снова с Вами не спорю, ведь программы такой и нет, это просто обсуждение теоретических возможностей.

  18. #48
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

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

  19. #49
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию Относительно Zachman Framevork

    Прежде всего, надо различать собственно Zachman Framevork - придуманную Джоном Захманом* в 1984г и многочисленные ее интерпретации - которые зачастую не имеют ничего общего с моделью Захмана и представляют собой вольный полет фантазии посторонних авторов. Почему авторы этих "творений" ссылаются на Zachman Framevork - остается загадкой.

    Желающие понять логику Захмана могут ознакомиться со статьей САМОГО "The Zachman Framework Evolution", опубликованной на сайте организации Zachman International:
    http://www.zachmaninternational.com/...es/100#maincol

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

    1. Модель Захмана является набором перспектив, представленных в виде двумерной матрицы.

    По вертикали расположены перспективы, представляющие собой различные взгляды на организацию как систему (проекции):
    SCOPE (OBJECTIVES) - ЦЕЛИ (контекстная)
    BUSINESS MODEL - МОДЕЛЬ БИЗНЕСА (концептуальная)
    SYSTEM MODEL - МОДЕЛЬ СИСТЕМЫ (логическая)
    TECHNOLOGY MODEL - ТЕХНОЛОГИЧЕСКАЯ МОДЕЛЬ (физическая)
    DETAILED REPRESENTATION - ДЕТАЛЬНОЕ ПРЕДСТАВЛЕНИЕ (взгляд программиста)
    FUNCTIONING ENTERPRISE - ФУНКЦИОНИРУЮЩЕЕ ПРЕДПРИЯТИЕ (взгляд пользователя)

    По горизонтали расположены модели, отвечающие в рамках перспектив на вопросы**:
    WHAT - HOW - WHERE - WHO - WHEN - WHY
    ЧТО - КАК - ГДЕ - КТО - КОГДА - ПОЧЕМУ

    То есть, в классической матрице Захмана содержится не менее 36 моделей. Это - серьезная работа.
    Мягко выражаясь. :-)

    2. В матрице Захмана нет иерархии. То что перспектива SYSTEM MODEL находится под SCOPE, вовсе не значит, что SM подчинена S и как-то получается из нее. Порядок по вертикали показывает уровень пользователя модели. И все.

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

    --------------------------------------------------------------------
    * - В 1980г компания IBM наняла Д. Захмана для разработки методологии Business System Planning. С этого все и началось ...
    надо же, и тут IBM отметилась. :-)
    **- видимо ребенок в детстве перечитал Киплинга. :-)

  20. #50
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    Забодали оба. Привязались к мелочи.
    Вот вам политкорректная новая редакция:
    "Нет чтобы продолжать заниматься поиском истины совместно с Дмитрием, так ты одновременно начинаешь искать истину еще с несколькими коллегами"
    Поиском истины каждый из нас занимается в одиночку.

  21. #51
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Александр Болдин
    В матрице Захмана нет иерархии. То что перспектива SYSTEM MODEL находится под SCOPE, вовсе не значит, что SM подчинена S и как-то получается из нее. Порядок по вертикали показывает уровень пользователя модели. И все.
    1. Спасибо.
    2. Вопрос. Можно ли разрабатывать SYSTEM MODEL, не определившись с SCOPE?

  22. #52
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    1. Спасибо.
    2. Вопрос. Можно ли разрабатывать SYSTEM MODEL, не определившись с SCOPE?
    1. Пожалста.
    2. Можно. Потому что там есть свой micro-SCOPE.

    Пример (интепретация моя)

    SYSTEM MODEL (level - designer)
    ЧТО? Логическая модель данных
    КАК? Архитектура системы (приложения, модули ...)
    ГДЕ? Распределение элементов архитектуры (города, офисы, серверы ...)
    КТО? Схема пользователей (виды, права ...)
    КОГДА? Регламент исполнения
    ПОЧЕМУ? Бизнес-правила
    Последний раз редактировалось А.Б.; 11.09.2009 в 14:45.

  23. #53
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Александр Болдин
    1. Пожалста.
    2. Можно. Потому что там есть свой micro-SCOPE.
    Сделать бы ход кон... микроскопом по голове!
    Таки ведь увернешься!

  24. #54
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Поиском истины каждый из нас занимается в одиночку.
    Не знал, что это теперь так называется

  25. #55
    Член сообщества
    Регистрация
    25.11.2005
    Сообщений
    1,731

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Пример (интепретация моя)
    SYSTEM MODEL (level - designer)
    ЧТО? Логическая модель данных
    КАК? Архитектура системы (приложения, модули ...)
    ГДЕ? Распределение элементов архитектуры (города, офисы, серверы ...)
    КТО? Схема пользователей (виды, права ...)
    КОГДА? Регламент исполнения
    ПОЧЕМУ? Бизнес-правила
    Содержательные ответы на все эти шесть вопросов от Маугли невозможно дать без обращения к уровням BUSINESS MODEL и SCOPE !

  26. #56
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Евгений_Кс
    Содержательные ответы на все эти шесть вопросов от Маугли невозможно дать без обращения к уровням BUSINESS MODEL и SCOPE !
    Невежда! Это не про Маугли, а про слоненка. Возьми томик Киплинга с собой на уикэнд - не пожалеешь. Это и полезнее, и приятнее, чем всяческие Голдратты.

    И это - поосторожнее со словами типа "невозможно".
    Я могу в рамках проекции* SM расписать внедрение "1С-Бухгалтерии" в компании, не привлекая BS, SCOPE и прочие... Легко - после перечисления на мой р/с аванса в размере 100% от суммы контракта.

    --------------------------------------------
    * - Сколько можно повторять: BM, SM ... это не уровни, а проекции (!). Это не я придумал, так у Захмана написано.
    Если так дальше пойдет, я скоро перестану быть добрым, блин...
    Последний раз редактировалось А.Б.; 11.09.2009 в 17:30.

  27. #57
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Коллеги, а вы какую матрицу Захмана обсуждаете?
    Репринт статьи в журнале IBM Systems Journal от 1987 г. (Zachman1.zip)?
    Или его более поздние труды (для модели Casewise Framework) (Zachman_Casewise.zip)?
    Захман ведь тоже не сидел сложа руки после первой статьи (1987). Та матрица была предназначена для IT-архитектуры и начиналась с данных (для ИТ первичны данные, которые нужно обработать - это их ЦЕЛЬ).
    А для Casewise он одобрил иерархический вариант, в которой первый столбец - Motivation -Why? - Зачем? (какова цель?) - Могу я так по смыслу перевести?.
    С уважением Виталий.
    Вложения Вложения
    Последний раз редактировалось eliferov; 11.09.2009 в 18:37.

  28. #58
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Коллеги, а вы какую матрицу Захмана обсуждаете?
    Репринт статьи в журнале IBM Systems Journal от 1987 г. (Zachman1.zip)?
    Или его более поздние труды (для модели Casewise Framework) (Zachman_Casewise.zip)?
    Захман ведь тоже не сидел сложа руки после первой статьи (1987). Та матрица была предназначена для IT-архитектуры и начиналась с данных (для ИТ первичны данные, которые нужно обработать - это их ЦЕЛЬ).
    Мы не обсуждаем никакую - потому что мой оппонент не читал Захмана. Когда прочитает, тогда это будет обсуждение, а пока так - пэрэпалька.

    Я же вам с ним дал ссылку на статью Захмана, где он сам описывает эволюцию своих подходов? Об чем речь?

    Я ведь не спорю - Casewise сейчас как программа наиболее близка к идеологии Захмана, но у нее и других недостатков хватает ... из-за чего ей не стать лидером рынка ... пока например их кто-нибудь не купит со всем их великобританским гонором.
    Цитата Сообщение от eliferov
    А для Casewise он одобрил иерархический вариант, в которой первый столбец - Motivation -Why? - Зачем? (какова цель?) - Могу я так по смыслу перевести?.
    Как переводчик переводчику: Переводить лучше в соответствии с правилами лингвистики и нормами языка.
    Why переводится Почему. А Зачем = What for.
    Цели это Objectives или Goals...

  29. #59
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Давайте включим логику.

    1. Исходное состояние матрицы Захмана - сплошные белые пятна с редкими вкраплениями отдельных моделей (например, схема базы данных бухгалтерии в формате SQL Server)
    2. Далее ячейки матрицы Захмана заполняются моделями по мере их разработки. Разработка моделей осуществляется параллельно-последовательно. Другими словами - в хаотическом порядке. :-)
    3. За годы прошедшие с начала заполнения матрицы подходы к моделированию неоднократно меняются, что вызывает переделки моделей и разрушение связей между ячейками.

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

    С уважением, АБ

    ЗЫ. Как обычно, я знаю где выход ... но не скажу

  30. #60
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    ЗЫ. Как обычно, я знаю где выход ... но не скажу
    "Как аналитик аналитику":
    Как обычно, ты считаешь , что знаешь, где выход...
    Как обычно, мнение проверяется практикой.
    Проверим, когда состаримся.
    С уважением Виталий

Страница 2 из 3 ПерваяПервая 123 ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •