Показано с 31 по 60 из 63
-
10.09.2009, 15:48 #31
- Регистрация
- 16.04.2009
- Сообщений
- 219
Дмитрий!
Вы меня извините, но Юлия начала тему с вопроса ТОЛЬКО ОБ АНАЛИЗЕ ОРГСТРУКТУРЫ.
Юлии, как в прочем и любому, кто пытается придумать, что-либо новое (именно придумать, а не использовать готовую методику) очень важны мнения и отзывы. Вот она и выложила в впопыхах условия, оторванные от программы, которые без дополнительных объяснений понять очень сложно. Но ничего, если будет интерес, я думаю, она всё подробно расскажет.
Подобную задачу я решал в 2003-2004 г. и начиналось решение не с оргструктуры, а с целей, затем процессов, а уж только потом - оргструктура. Об этом и матрица Захмана говорит, а модель Захмана - это 20% из всех методик мира (больше всех).
-
10.09.2009, 16:02 #32
- Регистрация
- 16.04.2009
- Сообщений
- 219
Вы правы в том, что клиенты голосуют ногами - вот когда ваша фирма догонит по обороту хотя бы 1С, тогда и поговорим.
Но и в целом с вашей формулировкой я не согласен. Успешный проект – это тот проект, который кормит своих создателей и приносит достаточно прибыли для дальнейшего развития. Когда проект достигает успешности уровня 1С, тогда видимо необходимость в подобных разговорах с Болдиным у них уже пропадает ;)
Из вашего сообщения видно, что вы путаете потребность в программе и потребности клиентов, которые эта программа должна удовлетворять. Надо с этим что-то делать.
P.S. А вообще, Болдин, почему Вы так конфликтно разговариваете? «когда дорастёте, тогда поговорим и прочее» Проблемы в работе или в личной жизни? Может кризис среднего возраста? Иль характер просто скверный?
-
10.09.2009, 16:19 #33
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Zerg
- Моделирование бизнес-процессов это рисование картинок со стрелочками. На самом деле, в моделировании наибольшую часть работы составляют: сбор информации, формирование веера приемлемых сценариев выполнения процесса, обоснование выбора оптимального сценария, выбор формы представления и его согласование с участниками процесса... и так далее. На фоне всего этого рисование диаграмм - детская задачка.
- Для моделирования бизнес-процессов компании необходим многопользовательский доступ к инструменту моделирования. Многопользовательский доступ нужен к результатам моделирования, но не к процессу разработки, а это легко достигается простыми средствами. Например, за счет интегрированности MS Visio в MS Office, диаграммы Visio можно публиковать в Интернет прямо из Visio. Не говоря уже о том, что их можно вставлять копи-пастом в MS Word или MS PowerPoint ... как мы чаще всего и делаем.
- В компании не найти двух одинаковых бизнес-процессов, они как отпечатки пальцев. На самом деле, подавляющее большинство БП - типовые. Уникальными являются процессы либо создающие ценность для покупателя либо ноу-хау позволяющие снизить затраты ... да и то они пестрят типовыми вставками.
Поэтому часто за утверждениями об уникальности наших процессов стоит элементарное желание пристроить хорошего человека на непыльную должность (ну там методолог бухгалтерского учета или что-то наподобие).
Я мог бы распространяться на эту тему долго, но времени немного, да и смысла не вижу.Последний раз редактировалось А.Б.; 10.09.2009 в 18:38.
-
10.09.2009, 16:42 #34
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Петров Дмитрий
Для самого загадка, но "необходимость в подобных разговорах" почему-то не отпадает ... даже у проектов с успешностью в разы превышающей 1С.
Сообщение от Петров Дмитрий
Сообщение от Петров Дмитрий
Сообщение от Петров Дмитрий
Ну и характер - тоже не сахар. Отрицать не буду. :-Р
-
10.09.2009, 16:55 #35
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Петров Дмитрий
Я правильно понял, что Вы считаете, что необходимо сначала ставить цели, затем строить бизнес процессы, которые будут эти цели достигать, а лишь затем формировать оргструктуру? Проблема в том, что подобная методика с легкостью применяется для новых или открывающихся предприятий. А программный продукт приобретают уже предприятия со сформированными целями, какой-никакой построенной оргструктурой, и уже существующими бизнес процессами (пускай и нерегламентированными). Не могут же они в один момент упразднить все должности и начать «с нуля».
Если начинать проект в работающей организации, то Вы тоже правильно поняли, но ....
Если Вы анализировали цели работающей организации и пытались выяснить: "Кто отвечает за достижение цели N?" - Какой ответ Вы получали?
Я думаю: "А кто её знает" или что-то покрепче. Это очень непростая задача, увязывать действующие цели и ответственность за них (причем это должна быть не BSC на бумажке). Мне это удается не более чем в 30% проектов. В остальных случаях - топы просто отпихиваю ответственность, а внешний консультант не может их заставить, только "внутренняя палка гендира или собственника".
Поэтому и приходится идти от обратного – строить оргструктуру, затем проверять какие функции эти должности выполняют в бизнес-процессах и давать рекомендации по изменению оргструктуры и/или процессов. Возможно, есть и другой способ, но я его пока что не знаю.
Цитата подлинная.
+ к Болдину:
4. Иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных.
Автор - Гради Буч. (Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2008 г), которого я рекомендую прочитать всем разработчикам.
Типов процессов действительно немного ( я насчитал пока 4).
С уважением Виталий.
-
10.09.2009, 17:33 #36
- Регистрация
- 16.04.2009
- Сообщений
- 219
то что вы видите как "конфликтность" есть стремление перевести дискуссию из статуса трепа в статус поиска решения. Без обострения результата не получите - так и будете трепаться ни о чем.
Я тоже за поиск решения. Каким Вы его видите в данной ситуации применимо к построении оргструктуры? Давайте всё-таки предположим, что необходимость в построении оргструктуры в программном продукте есть, пускай даже как вспомогательного элемента к другим функциям программы. Я не прошу изложить весь алгоритм, естественно это большая работа, но хотя бы основные положения того, что Вам, как потенциальному пользователю хотелось бы видеть в программном продукте.
Если Вы анализировали цели работающей организации и пытались выяснить: "Кто отвечает за достижение цели N?" - Какой ответ Вы получали?
Я думаю: "А кто её знает" или что-то покрепче.
Цитата из Положения о департаменте:"Участие в обеспечении организации взаимодействия между...." - как Вы это проанализируете и в какой бизнес-процесс отнесете?
Я могу быть неправ, но мне кажется, что стоит избегать написания ничего не значащих фраз в положения и ДИ. Если за фразой «Участие в обеспечении организации взаимодействия между....» не стоит каких-либо конкретных функций, за которые отвечает конкретный персонал, то и писать её не стоит.
Автор - Гради Буч. (Объектно-ориентированный анализ и проектирование с примерами приложений, 3 издание, : Пер с англ. М. : ООО «И.Д. Вильямс», 2008 г), которого я рекомендую прочитать всем разработчикам.
-
10.09.2009, 18:05 #37
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от eliferov
Причина в постсовковой системе мотивации построенной по линейному признаку - когда оплата труда зависит только от должности. Вспомни ситуацию в одной крупной телеком-компании с менеджерами проектов - начальство никак не могло понять, к какому классу их надо отнести (к мышам или тараканам)?
-
10.09.2009, 18:22 #38
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Петров Дмитрий
Движущие силы, формирующие систему управления организацией:
1. Процессы
2. Иерархия
3. Корпоративная культура
4. Стейкхолдеры
5. Лидерство
Эти силы, взаимодействуя друг с другом, собственно и создают некую схему взаимодействия людей в при осуществлении некоей деятельности - то есть Организацию. Организационная структура представляет собой моментальный снимок установившегося на данный момент равновесия 5 сил. Пытаясь нарисовать оргструктуру исходя из понимания какой-то одной силы (как например действуют консультанты - ВГЕ - без обид да?) мы с вами неизбежно создадим уродца - эдакого виртуального компьютерного монстра. При этом, реальное взаимодействие будет происходить по непонятным для нас правилам. Чисто по понятиям.
PS. Не ищите подтверждения или опровержения написанного выше в книжках - своего я еще не публиковал и аналогов не встречал. Нету времени на оформление хоть в каком-то виде. Потом как-нибудь ...Последний раз редактировалось А.Б.; 10.09.2009 в 19:22.
-
10.09.2009, 19:17 #39
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Петров Дмитрий
Согласен, цели, безусловно, важны. Вопрос лишь состоит в резонности привязки элементов оргструктуры и бизнес процессов к целям в программном продукте с учётом того, что цели (а особенно декомпозированные на более мелкие задачи) могут менять динамически и довольно часто, в то время как бизнес процессы и оргструктура подвержены изменениям намного реже.
Изменение цели - требует изменения процесса и, следовательно, изменения оргструктуры, ресурсов, технологий и т.д.
Я могу быть неправ, но мне кажется, что стоит избегать написания ничего не значащих фраз в положения и ДИ. Если за фразой «Участие в обеспечении организации взаимодействия между....» не стоит каких-либо конкретных функций, за которые отвечает конкретный персонал, то и писать её не стоит.
Хотя я специально написал: "Цитата подлинная".
С уважением Виталий.
-
10.09.2009, 19:46 #40
- Регистрация
- 16.04.2009
- Сообщений
- 219
Будучи патологически добрым, не буду вас отправлять в поиск на форуме - скажу сразу:
Движущие силы, формирующие систему управления организацией:
1. Процессы
2. Иерархия
3. Корпоративная культура
4. Стейкхолдеры
5. Лидерство
Как у "потенциального разработчика аналогичного продукта" у меня есть SRS на 200 с лишним страниц.
Хорошо Вам. Довольно интересно будет посмотреть на реализацию готового программного продукта.
Вы меня не поняли, или я выразился нечетко. Эта фраза УЖЕ НАПИСАНА и Ваш продукт должен будет анализировать этот бред.
-
10.09.2009, 21:12 #41
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Петров Дмитрий
А так, к сожалению, не выйдет Пока что нет таких технологий, чтобы анализировать произвольно написанные документы на «бредовость». Можно лишь наоборот, генерировать эти документы автоматом, вставляя информацию из процессов и оргструктуры.
Петров писал:
программный продукт приобретают уже предприятия со сформированными целями, какой-никакой построенной оргструктурой, и уже существующими бизнес процессами (пускай и нерегламентированными). Не могут же они в один момент упразднить все должности и начать «с нуля». Поэтому и приходится идти от обратного – строить оргструктуру, затем проверять какие функции эти должности выполняют в бизнес-процессах и давать рекомендации по изменению оргструктуры и/или процессов.
С уважением Виталий.
-
10.09.2009, 21:42 #42
- Регистрация
- 16.04.2009
- Сообщений
- 219
Под «какой-никакой оргструктурой» я подразумевал, что определены должности, сформированы подразделения, есть штатное расписание, возможно, определена административная подчиненность. Вот их и можно проанализировать, и то, только после того, как кто-то введёт эти данные в программу. Документы, написанные в вольной форме в Ворде программа естественно анализировать не может по техническим причинам.
Зато построив оргструктуру в виде дерева, назначив ответственность за бизнес процессы и выполняемые функции, назначив сотрудников на соответствующие должности такие документы как ДИ и положения о подразделениях можно на 70-80% генерировать полностью автоматически, перенеся подчиненность из дерева оргструктуры, ответственность из бизнес процессов, а функции из функций должностей, работающих в подразделении, используемые документы из бизнес-процессов, оттуда же взаимодействия с другими должностями по процессам и т.д. и т.п.
-
11.09.2009, 08:47 #43
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Существуют ли общие правила и рекомендации, применимые к построению административных организационных структур и возможна ли их автоматизация?
1.Да.
2.Нет.
1.По поводу общих правил.
Помимо модели Захмана есть еще близкое по смыслу высказывание Хезера Остерлоха, по памяти: Структура подчинена процессам, процессы подчинены стратегии.
2.По поводу возможностей автоматизации.
Кажется, Голдратту принадлежит высказывание, по памяти: главные параметры, определяющие деятельность организации, неизвестны и количественно неопределимы.
Следующее высказывание точно от Голдратта: «Организация – совокупность принятых кем-то ранее решений».
Решения по оргструктуре – важные решения для организации.
Они, во-первых, носят творческий характер, и, во-вторых, определяются сшибкой разнонаправленных движущих сил, о котрых писал Болдин.
Решения по оргструктуре – результат: 1)творческой 2)коллективной работы.
Формализовать выработку таких решений, уверен, нереально.
А делать мастырку, автоматизирующие указанные ниже в цитатах функции – на мой взгляд, не имеет смысла.
Если продиагностировать «узкие места» организации, то, полагаю, проблемы с указанным в цитатах функционалом окажутся далеко в хвосте проблем организации.
Проверять и анализировать мы можем лишь простые вещи, такие, как кол-во сотрудников занимающих должность, кол-во подчиненных сотрудников, кол-во выполняемых функций на 1 должность и т.д. и уж на основе этой информации пытаться давать рекомендации из разряда тех, что я привёл выше.Зато построив оргструктуру в виде дерева, назначив ответственность за бизнес процессы и выполняемые функции, назначив сотрудников на соответствующие должности такие документы как ДИ и положения о подразделениях можно на 70-80% генерировать полностью автоматически, перенеся подчиненность из дерева оргструктуры, ответственность из бизнес процессов, а функции из функций должностей, работающих в подразделении, используемые документы из бизнес-процессов, оттуда же взаимодействия с другими должностями по процессам и т.д. и т.п.
-
11.09.2009, 10:07 #44
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Евгений и Виталий,
По поводу схемы Захмана вы заблуждаетесь: в ней нет иерархии - это матрица. По Захману утверждение "Структура подчинена процессам, процессы подчинены стратегии" - ложно.
Статегия не определяет КАК должны быть построены и исполняться процессы, она лишь задает ЦЕЛИ - то есть базовые ориентиры, отталкиваясь от которых менеджмент компании формулирует цели и задачи элементов оргструктуры.
Не хочу никого обидеть... но главенствующий сейчас среди теоретиков подход к формированию систем управления напоминает мне подход М. Фарадея с помощью которого он в XIX веке описывал электромагнитные поля - на базе схем из пружинок, брусков, рычагов и тп.
...
Интересный факт: Фарадей, не понимая сути наблюдаемых им явлений, создал ряд законов, многие из которых работают до сих пор. В физике это называется "закон подобия" и те же физики уже используют инструменты, позволяющие определить когда этот закон работает, а когда нет.
-
11.09.2009, 10:33 #45
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Перестань. Первая строка в матрице Захмана - НАМЕРЕНИЯ.
См. хотя бы здесь: http://www.osp.ru/os/2001/12/180711/
"Захман предлагает признать, что компьютеры во всех их ипостасях есть всего лишь исполнительные элементы. Сами же по себе они ни архитектуры, ни системы не образуют. И архитектура, и система могут сложиться только в результате совместной деятельности всех участников процесса, в том числе владельца системы, проектировщика и строителя. Все должно происходить точно так же, как это бывает при строительстве дома, корабля или самолета" (выделено мной)
Ну ты силен.
Нет чтобы добарывать Дмитрия, так одновременно начинаешь бороться даже с соратниками
-
11.09.2009, 12:37 #46
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Евгений_Кс
Я бы и не парился... Армрестлинга и на работе хватает - лично мне на форуме интересно послушать мнения... в том числе по своим слабооформившимся мыслям.
-
11.09.2009, 13:19 #47
- Регистрация
- 16.04.2009
- Сообщений
- 219
Нет чтобы добарывать Дмитрия, так одновременно начинаешь бороться даже с соратниками
-
11.09.2009, 13:31 #48
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Забодали оба. Привязались к мелочи.
Вот вам политкорректная новая редакция:
"Нет чтобы продолжать заниматься поиском истины совместно с Дмитрием, так ты одновременно начинаешь искать истину еще с несколькими коллегами"
-
11.09.2009, 13:46 #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 отметилась. :-)
**- видимо ребенок в детстве перечитал Киплинга. :-)
-
11.09.2009, 13:49 #50
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Евгений_Кс
-
11.09.2009, 14:05 #51
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Александр Болдин
2. Вопрос. Можно ли разрабатывать SYSTEM MODEL, не определившись с SCOPE?
-
11.09.2009, 14:31 #52
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Евгений_Кс
2. Можно. Потому что там есть свой micro-SCOPE.
Пример (интепретация моя)
SYSTEM MODEL (level - designer)
ЧТО? Логическая модель данных
КАК? Архитектура системы (приложения, модули ...)
ГДЕ? Распределение элементов архитектуры (города, офисы, серверы ...)
КТО? Схема пользователей (виды, права ...)
КОГДА? Регламент исполнения
ПОЧЕМУ? Бизнес-правилаПоследний раз редактировалось А.Б.; 11.09.2009 в 14:45.
-
11.09.2009, 14:40 #53
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Александр Болдин
Таки ведь увернешься!
-
11.09.2009, 14:41 #54
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Александр Болдин
-
11.09.2009, 14:53 #55
- Регистрация
- 25.11.2005
- Сообщений
- 1,731
Сообщение от Александр Болдин
-
11.09.2009, 17:07 #56
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Евгений_Кс
И это - поосторожнее со словами типа "невозможно".
Я могу в рамках проекции* SM расписать внедрение "1С-Бухгалтерии" в компании, не привлекая BS, SCOPE и прочие... Легко - после перечисления на мой р/с аванса в размере 100% от суммы контракта.
--------------------------------------------
* - Сколько можно повторять: BM, SM ... это не уровни, а проекции (!). Это не я придумал, так у Захмана написано.
Если так дальше пойдет, я скоро перестану быть добрым, блин...Последний раз редактировалось А.Б.; 11.09.2009 в 17:30.
-
11.09.2009, 18:31 #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.
-
11.09.2009, 19:30 #58
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от eliferov
Я же вам с ним дал ссылку на статью Захмана, где он сам описывает эволюцию своих подходов? Об чем речь?
Я ведь не спорю - Casewise сейчас как программа наиболее близка к идеологии Захмана, но у нее и других недостатков хватает ... из-за чего ей не стать лидером рынка ... пока например их кто-нибудь не купит со всем их великобританским гонором.
Сообщение от eliferov
Why переводится Почему. А Зачем = What for.
Цели это Objectives или Goals...
-
11.09.2009, 19:46 #59
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Давайте включим логику.
1. Исходное состояние матрицы Захмана - сплошные белые пятна с редкими вкраплениями отдельных моделей (например, схема базы данных бухгалтерии в формате SQL Server)
2. Далее ячейки матрицы Захмана заполняются моделями по мере их разработки. Разработка моделей осуществляется параллельно-последовательно. Другими словами - в хаотическом порядке. :-)
3. За годы прошедшие с начала заполнения матрицы подходы к моделированию неоднократно меняются, что вызывает переделки моделей и разрушение связей между ячейками.
В этих условиях предлагаемая вами господа метода заполнения матрицы от левого верхнего угла к правому нижнему - чистой воды маниловщина.
Попробуйте опровергнуть. :-Р
С уважением, АБ
ЗЫ. Как обычно, я знаю где выход ... но не скажу
-
12.09.2009, 00:27 #60
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
Сообщение от Александр Болдин
Как обычно, ты считаешь , что знаешь, где выход...
Как обычно, мнение проверяется практикой.
Проверим, когда состаримся.
С уважением Виталий