Мысли вслух

• Спам и закон торможения.
  Статья рассматривает причины возникновения спама и причины отсутствия решения этой проблемы.
• ТРИЗ умер. Даздравствует ТРИЗ!
  .... продолжение....
  Статья рассматривает проблемы и неточности ТРИЗ и дает возможные пути их решения.

  ---

Статьи о программировании

• Правда и мифы о DBF и xBase
  Статья рассматривает и опровергает устоявщиеся взгляды на DBF и xBase.

  ---

• Нужен ли специальный язык для информ. систем
  Статья Юрия Хныкина с концептуальным взглядом на язык программирования для информационных систем

  ---

• Сравнение ОО-моделей нескольких популярных языков программирования
  Статья Павла Лазарева

  ---

• Вторая жизнь ПК и DOS-программ
  О работе DOS-приложений в связке Linux+dosemu

Статьи об управлении, бухгалтерском и управленческом учете, принципах и подходах в создании информационных систем управления (ИСУ).

• Манифест информационых систем управления (ИСУ)
  Основные термины и определения, в науке построения ИСУ
• Переписка к Манифесту

  ---

• Реинжиниринг: не автоматизируйте - уничтожайте
  Классико-историческая статья М.Хаммера

  ---

• Что такое (ре)инжиниринг, и при чем тут бизнес
  Критика BPR
• Переписка к статье

  ---

• Кое-что о моде, бизнес-реинжиниринге и НОТе
  Статья М.Каменновой и А.Громова в "ОС" N3(17)/96

  ---

• Цепочки поставок и информационные системы,
  или История одного недоразумения
  Статья Н.Чувахина об азах SCM (Supply Chain Managament)

  ---

1. Если есть ИНФОРМАЦИОННАЯ система управления, значит есть и, как минимум одна, другая (НЕИНФОРМАЦИОННАЯ) система управления (это общая сложнейшая проблема разумного использования прилагательных) ?

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

После ввода понятия "фирма" было бы разумно ожидать понятия "система управления фирмой", или после ввода понятия "бизнес-процесс" разумно ожидать понятия "система управления бизнес-процессом"; еще логичнее, учитывая авторское Отрицание 2, использовать понятия "управление фирмой" или "управление бизнес-процессом".

А смысл? По моему из введения ясно видно о каком управлении идет речь.

2. Почему на промышленном (автотранспортном, строительном) предприятии редко (мягко говоря) возникает проблема выбора между готовым металлорежущим станком (автомобилем, башенным краном) и собственной разработкой, а "проблема выбора между готовым программным комплексом и собственной разработкой" возникает часто ? Конечно, это просто "традиция" - наследие отделов АСУ.

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

3. Если бизнес-процесс - это деятельность фирмы в рамках производства одного вида продукции или оказания одного вида услуг, то почему реорганизация бизнес-процесса - это не реорганизация деятельности фирмы в рамках производства одного вида продукции или оказания одного вида услуг, а целевая деятельность управления по совершенствованию ИСУ ? Причем здесь ИСУ ?

Повторяю еще раз. Чтобы абстрагироваться раз и на всегда от бизнес инжиниринга. В этом отношении ключевой вопрос и судьба манифеста. Или вы признаете что действительно можно заменить искусство управления на инженерную дисциплину, тогда ваш удел BPR, или вы относитесь к управлению как к творческой деятельности. Вообще вопрос ключевой. Я начисто отвергаю BPR как практическую теорию. Манифест несколько преждевременен. Надо бы выдать свою теорию для начала, но это для меня неподъемная задача из-за дефицита времени. Найдутся сподвижники может осилим. Назову условно - теория эффективного управления ТЭУ. Основные отличия:
Бизнес
BPR - инженерная дисциплина
ТЭУ - творческая деятельность
Процесс
BPR - четкого определения нет, у разных авторов разный. Нечто имеющее входы и выходы, ресурсы, владельцев, разные цели и разную ценность. Отсюда все эти "цепочки бизнеспроцессов", которые уже оскомину набили. С точки зрения инжинирга это некая деталь или узел. Но если ситуцию перевернуть, это будет выглядеть так, как будто документацию на карбюратор мы будем делать не в виде чертежей, а в виде словесного описания в стихах, если до конца отстаивать что и в технических дисциплинах имеется творческий подход. Да есть инженерное творчество. Летают красивые самолеты и в академии живописи преподают анатомию человека. Но заменить искусство управления на инженерную дисциплину, как это предлагают апологеты инжиниринга бизнеса, это кощунство.
ТЭУ - см. манифест.
Процедура
BPR - близко это у них называется прецендентом. Но все дело в том, что управлению нужен не сам прецендент, а информация о фактах. И желательно сразу с анализом. Все, сваливаемся к теории информации и управления. Кража со склада ящика водки равно как и выполнение рабочими своего задания сами по себе на поведение управленцев никак не влияют и в поведении всей фирмы ничего не измениться. Необходима информация об этих событиях. В общем отсылаю к Хендриксену и Ван-Бреда "Теория бухгалтерского учета".
ТЭУ - см. манифест

4. Можно предположить, что бизнес-процесс - это аналог технологического процесса. Тогда почему его составная часть называется бизнес-процедура, а не бизнес-операция ? И почему бизнес-операция должна быть обязательно "документально оформлена"?

Да, это АНАЛОГ техпроцесса, но всего лишь аналог. Именно поэтому процедура, а не операция. Операция связана с преобразованием материальных и нематериальных активов. Процедура может быть и не связана н.п. "заключение договора", "оформление приказа", "получение сводки" и т.д. "Документальное оформление" может быть и не бумажным. Важно зафиксировать факт детально и формализовано его описав. Операция обязательно должна быть выполнена, так как иначе не начать следующей. Процедура тоже обязательна по определению. Но ее неисполнение может и не оказывать влияние на сам производственный процесс. Взял со склада молоток и стучу себе. Техпроцесс не нарушаю. Кого это волнует? Подумаешь, малоценку они не списали...

Бизнес-операция (хозяйственная операция) - это функционально законченная часть бизнес-процесса.

Как описываются функциональные границы законченности?

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

Типичная ошибка нивелировать значение бухгалтерского учета. И я этим очень обеспокоен и встречается она уже не первый раз. Бухучету можно СОПОСТАВИТЬ статистический учет. Например народонаселения так как жизнь человеческая и в копейку не цениться.
В каких еденицах будем вести учет "деятельности фирмы"? Человеко-километрах или тонно-трудоднях?
ДЕНЬГИ ЕСТЬ УНИВЕРСАЛЬНОЕ ИНФОРМАЦИОННОЕ МЕРИЛО ЛЮБОЙ ЦЕННОСТИ. Будь то материальный-нематериальный объект или услуга. Если кого-то интересует количество бумажек с цифрами лежащими в сейфе это его дело. Вопрос бухучета "сколько у нас в кассе" ответ "шесть баксов, что в рублях составляет шестьсот по курсу ЦБ, шестьсот двадцать по курсу нашего банка, шестьсот пятьдесят на бирже в Чикаго, или два лимона в монгольских тугриках или ....или..."

6. Релевантность, толерантность, репрезентативность. Только люди начали свыкаться с инкапсуляцией, наследованием и полиморфизмом, как на тебе. Может что-нибудь попроще, например, необходимость, достаточность, точность информации ?

Абсолютно согласен на счет простоты! Но тогда придется или расширять количество понятий - "важность, неожиданность, относительность, актуальность, адекватность и т.д." или строить дерево вхождений. Лично мне такая математическая раскладка "необходимость-достаточность-точность" очень нравиться. Есть повод обмозговать. Если Вам удастся в эти три понятия втолкнуть все остальное, рад буду скооперироваться. Тут вопрос например такой - как определить границы достаточности? А приемлемая точность. Вопросы...

Насчет "полиформизма" и т.д. и всего того, что называется объектно-ориентированным подходом. Буржуи проклятые сделали из него догму и молятся на него как коммунисты в свое время на свой манифест.
Оъекты, методы, классы, наследование-полиформизм-инкапсуляция, все это удел технически-определенных систем с известными входами-выходами-ресурсами-владельцами- воздействиями-сущностями-связями и т.д. Под это дело заточены IDEF, CASE, ERP и прочее. И замечательно работает и ничего против не имею.
Но еще раз говорю для определенных систем! Если мы проектируем машину, то в зависимости от начальных условий она будет или на колесах или гусеницах или гравитационной подушке. Набор этих методов известен. И ни кому не придет в голову под конкретную модель изобретать новый движитель.
В информационной системе мы имеем дело с непределенностью. Энтропией. Если я сегодня дал в долг ,то я только относительно могу знать когда и чем мне этот долг вернут, монетой, бумагой бартером или переведут стрелки. А моделировать свое поведение мне нужно. Мне нужно знать на какой срок я обеспечен заказами, до достижения точки банкротства. А эта точка бегает то дальше то ближе после каждой процедуры, после каждого скачка курсов и ставок, после налета саранчи на урожай кукурузы.
С точки зрения ООподхода вы разрабатываете определенную систему: проект, закладываете фундамент, ставите стены, сверху крышу, приглашаете заказчика и подписываете процентовку. Именно так описавается подход в инжиниринге бизнеса. Рекомендую полюбоваться у Ойхмана и Попова "Реинжиниринг бизнеса" ФИС, 1997.
Если с таким подходом проектировать информационную систему то она рухнет с первым капризом заказчика которому не понравится фасад. Потомучто вы никаким макаром не сможете учесть все "IF'ы" в этом процессе. Начиная от качества кирпича, кончая укус прораба ядовитым пингвином.
Иное дело ПРОЦЕДУРНО-ОРИЕНТИРОВАННЫЙ ПОДХОД. Не надо путать с объектно-ориентированным программированием. Разбейте процесс на процедуры: "оформление заказа,согласование проекта, оформление и учет нарядов, составление сметы, процентовка и т.д.", и тогда каприз заказчика к смене фасада сведется к выполенинию уже известной процедуры "составление сметы" на демонтаж и выполнение нового. Процедуры не есть "цепочка". Они независимы и последовательность их условна. Они легко "наследуются, полиформятся и инкапсулируются" независмо от всей машины и не требуются обвальной перекомпиляции всего механизма. Процедура становится объектом (или наоборот? :)). Бизнес это процесс стохастический. Здесь работают другие понятия. Это объект-субъект, время-место, количество-качество, процесс-процедура. Элементарные философские категории. Легко гармонируют с языком бухучета и со всем остальным.

В принципе неплохо. Но не совсем. Для работы механизма "достаточно" "нормальной" работы. И требовать от него большего чем было заложено в проекте бессмыслено. Иначе требуется перепроектирование, тот самый реинжиниринг, мать его.
Для такой животрепещущей, животно-разумно-подобной системы как бизнес, просто "необходимо" сокращать время реакции на уклоняющие воздействия.
В механической системе запаса инерции может хватить чтобы сохранить устойчивость в последовательном направлении ее движения. В бизнесе я инерционность плохо представляю. Допустим мы торгуем товаром с ограниченным сроком реализации. Половину товара распродали. Половина осталась не распроданной. Сгноили, выкинули. Показатель оборачиваемости товара расчитываем в конце месяца и сидим довольные. Если бы мы его контролировали каждый день, то уже через две недели видели бы что все не продадим и меры предпринять бы успели. Допустим то что сгноили покрылось высокой наценкой и все равно мы в профите. Нормально? Нормально. Глупо? Глупо.

8. Принцип открытости систем как раз нуждается в тщательных комментариях. Нужно четко пояснить существо проблем, возникающих из-за естественного требования доступности для дальнейшего развития самим пользователем программы ЭВМ, структуры базы данных, металлорежущего станка, самолета, башенного крана.

Да.

PS: О создании общества. Сначала нужно провести анализ существующих обществ с близкими идеями. Чтобы создать работоспособную и, главное, влиятельную структуру. Рабочее название, с глубоким уважением к "застрельщику" Андрею Куликову: АЖУР - ассоциация желающих управлять разумно.

Та-а-щ-щусь!