Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Водолей

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »
421
поэтому-то термин "общесистемные процессы" является неудачным.
причем было бы логично, что "общесистемная оптимизация" относится к оптимизации все системы, а не к отдельным ее элементам - т.е. оптимизация в широком смысле в отличии от оптимизации в узком смысле (в вашей трактовке - предметной)

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

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




423
Цитата: div
А BMW - БиЭмДаблви?

Дабл-ю :о)))

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

 

425
2 Asd:
попробую свою мысль сформулировать следующим образом: если систему можно улучшить, то алгоритм (или даже алгоритмы) оптимизации существует (это аксиома своего рода).
пусть даже он не будет реализован в к.-либо программной системе, но будучи выполнен - он даст заранее известный результат. безотносительно трудоемкости выполнения, просто выполнили - получили результат.
теперь задайте себе вопрос: что могло бы быть предметом/объектом (не целью! про цели было выше) изменения? что именно вы будете менять?

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

Цитата: Galogen
А еще есть теория ограничения систем ТОС, тоже в этом плане очень интересна

и??? ведь книжка Голдрата не зря называется "Цель...."

426
дополнение
в наших компаниях столько еще можно улучшить не прибегая с тяжелым технологиям

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

про методологию я не говорил :о)) я говорил про уровень владения софтом, в IDS IMHO несколько повыше (они все-таки не такие крупные и имеют отношение к родоначальникам жанра). из второго первое не следует.
и потом, в наших компаниях столько еще

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


428
Цитата: Asd
Перенос функции из точки А в точку В врядли подполает под это определение.

Вы уж определитесь что у Вас и какими буквами обозначается, что за самодеятельность такая: то А и В - функции, то А и В - точки? :о))) Написали "функция А из точки Х в точку У" так и продолжайте :о))))

а если серьезно, то все зависит от... многих факторов: что такое "принципиальное переосмысление", что такое "радикальная перестройка", что такое "кардинальное улучшение", что такое "критические показатели" - В ДАННОМ КОНКРЕТНОМ СЛУЧАЕ!
ведь может статься, что заставить какую-нибудь мариванну правильно оформлять накладную и ставить свою подписть - это реинжиниринг в квадрате, если не в кубе :о)))) реальные примеры тому имеются.


429
2 Asd:

методика, как это ни странно, есть. имеется ряд книжек, написанных Августом Шеером (у нас, правда, издана 1 или 2, и их можно найти в интернете). но ведь никто их не читает. целью проекта ставится наличие моделей. вот и рисуется ...эээ... всякая ерунда, которой невозможно пользоваться совершенно.

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

про ABC. для уверенного и правильного (!!!) использования этой методики IMHO мало концептуального знания :о))) Вы же говорите об оптимизации. Вы математику какую-нибудь в школе/институте изучали? ну там где исследуется какая-либо функция, локальные/глобальные экстремумы и т.п. так вот по сути предприятие - это тоже функция, только формулку для описания взаимосвязей параметров написать сложновато. по сути модели и являются этими формулами. а в математике известен тезис о том, что чем больше неизвестных и чем сложнее система уравнений, тем более сложны методы, которые нужно использовать для ее решения. причем, не стоит забывать факт, что не каждая система имеет решение.
так что я Вам рекомендую не лениться, особенно если результат Вашей работы зависит всего лишь от "ввода абсолютных значений стоимости и времени".

приводимые Вами примеры про "функцию А", "точки Х  и У" IMHO не подходят к термину "оптимизация", скорее к "реинжинирингу"

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

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

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



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

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

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

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

P.S. Хотя книжки Шеера вполне адекватны и понятны. Осталось "потренироваться на кошечках"... Кошечки! Где вы?

431
начать все равно надо с целей, критерии ее достижения уже потом, вместе со способом измерения (проверки).
по сути критерии оптимизации довольно просты: уменьшить время рабочих операций, сократить складские запасы и т.д. и т.п.
берется соотношение: результат / затраты и выполняется работа по увеличению частного. из формулы очевидно, что это может быть достигнуто либо за счет увеличения "количества" результата, либо уменьшения "количества" затрат, либо и то и другое вместе взятые.
результаты оптимизации IMHO всегда достигаются за счет творческой работы, главное, чтобы данных для нее было достаточно, а тут очень существенным становится качество моделирования. и нужно соблюдать довольно тонкий баланс между полнотой и значимостью информации. т.е. модель-то составить просто, а вот хорошую модель, применимую для ваших задач совсем нетривиально. это про as is. а уж про to be вообще отдельный разговор
насчет локальных ситуаций во многом не согласен, т.к. некоторое локальное решение, будучи примененным в масштабе организации, может значительно повысить соотношение. отсюда может быть сделан (или не сделан :о))) вывод о том, что унифицированные процессы лучше, чем неунифицированные хотя бы потому, что возможные потери уже известны (лежат в основе унифицированных участков) и не могут сами по себе безразмерно увеличиваться. а это тоже повышает соотношение.
боюсь, что настолько формальных методов (как вы желаете) я вам подсказать не смогу - без комментариев "почему?"

P.S.  а вообще есть методика ABC, слышали?

432
вообще-то бизнес процессы далеко не всегда моделируются с целью оптимизации. далее, для построения моделей to be необходим набор требований, которым эти модели должны удовлетворять в отличие от as is, иначе получится переделка ради переделки.
а для оптимизации было бы неплохо сначала задать критерии, по которым процессы будут оптимизироваться (в конечном счете те же стоимость, время и т.п.)

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

433
Цитата: Galogen
Не ну это как тебе хочется. Публичное изъявление может быть полезным, а может бесполезным.

ОК, не вопрос.

Цитировать
Кажется пришло решение.

ну и хорошо! посоветую все-таки набросать макет, чтобы убедиться в соответствии решения ожиданиям.


434
к сожалению, не обладаю достаточным временем чтобы вникнуть в тонкости. но если встречусь с министром здравоохранения, обязательно спрошу, вероятнее все-таки встреча с кем-то из заместителей (честно!).
из всего сказанного, вариант с ведением самостоятельно справочника ПКГ/ПКУ мне представляется наиболее целесообразным. при присвоении атрибутов для должности пара ПКГ/ПКУ (и возможно что-то еще) просто будет выбираться из этого самостоятельного справочника. это как раз позволит устранить ту коллизию о которой ты говоришь, а именно:
Цитировать
Т.е. хранить эту информацию непосредственно у должности кажется неправильным, т.к. тогда придется скажем создавать две и более записей с одинаковым названием должности и разными ПКГ/ПКУ
может быть будет еще правильнее задавать для должности не единственный вариант, а набор ПКГ/ПКУ? а когда сотрудник занимает должность, стоит ассоциировать с ним конкретный ПКГ/ПКУ? тогда возможные варианты останутся для вакантных должностей, что позволит претендовать на должность сотрудникам с разной (но подходящей!) квалификацией.

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

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

как-то так...

P.S. похоже, мы постепенно выходим за рамки тематики форума, может лучше в личку пойдем?



435
не знаю уж, правильно ли я понял термин "учесть" :о)) но IMHO есть два варианта:
1. вести отдельные (скорее всего иерархические, судя по твоему ответу) справочники ПКГ и ПКУ, а при задании (вводе) новой должности или корректировки параметров имеющейся указывать ПКГ/ПКУ, выбирая нужные значения из справочников. так как, судя по твоему ответу, они взаимосвязаны, может быть будет достаточно выбирать что-то одно (ПКУ), а всё остальное будет заполняться в должности автоматически
Сами справочники ПКГ и ПКУ придется вести в соответствующих отдельных режимах, возможно это будет плюс, а может лишний геморрой.
2. задавать значение ПКГ и ПКУ каким-нибудь кодом, тогда справочник не нужен, но нужно будет знать и правильно употреблять эти коды.
может быть возможен третий - что-то промежуточное.

в первом случае - ПКГ/ПКУ - отдельная сущность, во втором - это просто некоторый набор метаданных.

что касается привязанного к ПКГ оклада, то в случае со справочником, он будет задаваться в справочнике, в должность копироваться. во втором варианте циферки оклада придется задавать ручками прямо в должности. IMHO первый лучше, так как при исключении должности из ШР, будет оставаться информация об окладе, связанном с ПКГ. да и вообще система ПКГ/ПКУ может оказаться достаточно сложной и разветвленной, может быть неудобно вводить руками, хотя варианты можно придумать (составной код тот же)

может стоит попробовать на макете (хотя бы в виде paintbrush-программирования) оба варианта или какие там еще придумаются.



Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 »