Решил поделиться накопленным за 8 лет опытом в с сфере разработки, внедрения и сопровождения автоматизированных систем уровня предприятия. Речь не пойдет про контроллеры и АСУТП или про ERP с бухгалтерскими делами, а расскажу про то как мы делаем то что между ними, где уже нет датчиков, но еще нет и денег, а есть заготовки, полуфабрикаты, изделия, станки, технологи, плановики и отчеты.
Кому интересна эта тема добро пожаловать…

Многие знают о ”культе карго” — удивительном явлении, имевшим место во время Второй мировой войны. В ходе боевых действий удаленные острова в Тихом океане вдруг стали стратегическим объектом, американцы построили на них военную базу, и местные туземцы были осчастливлены продуктами цивилизации, которые доставляли грузовые самолеты. Туземцы решили, что хитрый белый человек, который сам не производит никаких материальных ценностей, получает их напрямую от богов, выполняя загадочные ритуалы: марширует с палками по плацу, сидит возле ящика с антенной и молится на непонятном языке, призывая небесных птиц. Когда война окончилась, американцы оставили острова и их наивных обитателей. Когда же позднее на остров вернулись исследователи, они с удивлением обнаружили туземцев с нарисованными нашивками, марширующих по плацу и шаманов, призывающих ”карго” в деревянных наушниках перед муляжом радиостанции.

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

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

Короткий ответ

ITSM – Information Technology Service Management

Чуть более длинный ответ

ITSM – это область знаний об управлении деятельностью по оказанию ИТ-услуг. Основных исходных посылок, принятых в ITSM, две: во-первых, услуга – это основная форма предоставления ценности, исходящей от ИТ, во-вторых, деятельность по оказанию ИТ-услуг лучше всего организовать как комплекс процессов с четко определенным целями, задачами, ролями и обязанностями.

ещё более полный ответ под катом

Занимаясь автоматизацией производства, разработчики сталкиваются со множеством проблем. Но две из них волнуют всех:
1. Передача данных с объекта.
2. Организация базы данных.

По мотивам недавнего топика.

In a better world…

По-идее, in a better world, правительство принимает постановление, потом ещё одно, президент даёт поручение, министры, губернаторы и мэры их исполняют и выпускают свои, выделяются деньги, нанимается команда профессионалов, и… через какое-то время появляется «Облачное ЖКХ». В облачном ЖКХ не только учет показаний приборов учёта (на что давил предыдущий автор), но и прозрачность, Интернет-кабинеты, оплату и разборки абонент устраивает сидя на диване с кредитной картой и видеокамерой, УК сокращают штат, РСО ремонтируют сети и устраняют утечки, информация прозрачна, доступна и собрана в одном месте, бухгалтерия доступна, деньги не воруют. Видя это, управляющие компании рады – они же автоматизировали столько работы, их не напрягают вопросами и скандалами жильцы – всё ведь видно и прозрачно, жильцы, довольные красивыми картинками говорят спасибо управляющей компании и голосуют «за» президента, однако…

Life is a bitch

Бродил я тут по сайту университета Беркли и набрёл на вот такое меню (которому уже невесть сколько лет). Да, в Беркли всегда знали, что на самом деле нужно для развития IT-индустрии.

Итак, коллеги, продолжим дорожную тематику. Мхатовская пауза с момента моей последней публикации до неприличия затянулась, а на сходные темы статей все нет. Память народная слаба, и мне уже начали присылать ссылки на мои же собственные посты. Дабы утолить информационный голод рискну завести речь о платных дорогах.

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

У нас в стране как грибы после дождя стали возникать разрозненные куски и фрагменты платных магистралей. В планах государства тотальное строительство тысяч километров платных дорог, по которым автомобили простых россиян рванут прямо в светлое будущее… Со всех сторон подступают желающие вложиться в столь выгодное предприятие и наперебой предлагают свои «высокотехнологичные» решения. Которым, в общем-то, и хотелось бы посвятить остаток данного текста.

При организации взаимодействия систем, принадлежащих различным организациям, возникают вопросы по реализации интеграции ИС и юридическо – правового плана. Хотелось бы поделиться небольшим опытом и выводами, полученными в проектах такого плана. Информация может показаться интересной аналитикам, проектировщикам, разработчикам и может интересующимся руководителям.

Что делать, если разработка ТЗ не самого сложного проекта занимает пару месяцев? Какие шаги при разработке ТЗ могут уберечь от рисков и ошибок? В данной статье мы рассмотрим проблему не содержания документа, а методологию его разработки.

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

IBM и один из крупнейших финансовых институтов мира — Citibank, договорились о том, что Watson будет обрабатывать неструктурированные финансовые данные компании для того, чтобы лучше управлять рисками, а также анализировать пожелания клиентов банка, с целью выстраивания наиболее современной и продвинутой системы электронного банкинга.

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

Готовя очередную Служебную записку своему руководителю, я немного перестарался. Служебка вышла на 30 страниц с таблицами, схемами и графиками. Озаглавлен этот документ «Как создать в компании эффективную систему». Кому-то это может показаться банальным и неинтересным, но многие, мне кажется, смогут найти в этом что-то полезное для себя или своего бизнеса.

Есть такая конференция ADD (Application Developer Days) на которой любят всякие архитектурные штуки для разработки ПО обсуждать, обычно эти штуки заканчиваются тоже на xDD — DDD, TDD, MDD и т.д.

Вот к примеру на прошлой конференции задались вопросом, а что такое DDD (Domain Driven Design)?
А Николай Гребнев из CUSTIS — встал и ответил.

Видео доклада:

Добрый дня всем!

В этой статье я не буду касаться технических вопросов и не приведу примеров кода. Эта статья призвана дать понятие, что такое Rule Engine, для чего эта штука и что она умеет. Если вас заинтересует такой подход к построению систем, то вы без проблем найдете Rule Engine на ваш вкус и цвет.

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

Вопросы и ответы

Задайте себе вопросы:

• Кто, как и на основании чего решает, в каком порядке самолеты садятся и взлетают?
• Какова может быть цена неверного решения?

Второй вопрос проще, поэтому ответим сначала на него. Минимальная цена это несколько десятков тысяч евро, а вот максимальная несколько сотен человеческих жизней. А теперь к первому вопросу.

Итак, кто? Ответ: в большинстве случаев люди. Не без помощи компьютеров конечно, но все таки люди. Теперь вопрос: как? Есть список возможных вариантов, человек из них выбирает. Вариантов дается немного, поэтому в принципе особых мук выбора нет. И последний вопрос: на основании чего? Есть правила, их нужно придерживаться и по возможности выполнять. Например, задержка вылета более чем на полчаса весьма нежелательна. Ну и главный вопрос: а причем тут Rule Engine?

 

Как и обещал, начинаю выкладывать вторую часть «методички». В этом фрагменте общие принципы и подходы, на которые я опираюсь во всех дальнейших размышлениях и выводах.
Построение эффективных бизнес-систем. Глава 1: Введение

В продолжении предыдущей публикации по теме Domain Driven Design, где Николай Гребнёв последовательно свёл тему проектирования при помощи DDD к необходимости использования языка предметной области, — в данной публикации будет обсуждаться практика проектирования и разработки как самих языков, так и программирование на них (опыт компании JetBrains).

Доклад smax Максима Мазина с прошлогодней конференции архитекторов ПО Application Developers Days

Видео доклада:

Скачать

ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/1a1-language-oriented-programming-mazin.avs.avi

Презентация

docs.google.com/present/view?id=dccwwvbq_729dxjj82gc

Текстовка доклада (выполнена Belonesox)

Автор рассказывает о перипетиях пивоваров, производителей СУБД, себя и кратко о том как правильно проектировать приложения. Мне показалась полезной поучительная часть статьи.

На данный момент, мы проделали колоссальную работу, выявив основные потоки компании, и расположив их в идеальном порядке. Я говорю «мы», поскольку полагаю, что вы вместе со мной строите эту схему, и она вам полностью понятна. Если это не так, то, возможно, имеет смысл вернуться в начало документа. Если и это не вносит ясности, то задавайте вопросы автору.
Но, оставим на время сложные схемы и вернёмся к простым примерам. Поточный подход к организации бизнеса позволяет применять простые технические законы к нашей компании, извлекая из этого много полезных уроков.

Основная сфера моей работы на протяжении 16 лет – автоматизация деятельности предприятий. Поскольку начиналось все еще в 1996 году, в небольшом городе и в отсутствии литературы по программированию персональных компьютеров – то все делалось методом проб и ошибок или «методом научного тыка». Времена поменялись, появилось множество методик (сам ими не пользуюсь) по автоматизации, внедрению и поддержке ПО для автоматизации деятельности.