CustisWiki - Новые страницы [ru]

Право на справедливые расчеты

2010-04-28T16:35:23Z

BenderBot: 1 версия

Андрей Борейко, заместитель директора по развитию бизнеса ООО «Заказные ИнформСистемы».

«Право на справедливые расчеты»^[1]

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

Неудовлетворенность субъектов рынка ЖКУ сегодняшним положением имеет вполне объективные основания.

К недовольству населения ростом тарифов на ЖКУ добавляются жалобы на частые случаи несправедливых расчетов. Это проявляется, например, при учете недопоставки услуг. Во многих городах сохраняется неудобная для населения система контактов с поставщиками, когда у каждого из них имеется своя, отдельная абонентская служба.

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

Поставщики ЖКУ, естественно, тоже страдают от этого недоверия.

Местная власть, в свою очередь, не может самоустраниться от проблем управления жильем хотя бы потому, что именно на нее граждане возлагают ответственность за проблемы с ЖКУ. Этот вопрос носит политический характер и влияет на конкурентоспособность муниципального образования, на его привлекательность для жизни и бизнеса. Между тем, по мере коммерциализации отрасли ЖКХ, муниципальные органы теряют рычаги влияния на ситуацию. Поэтому город должен найти способ отчуждать информацию о жилье, об инфраструктуре и об абонентах управляющих организаций.

Потребность в общегородских информационных ресурсах по мере реформирования ЖКХ не исчезает, а обостряется. Надежным источником таких ресурсов могут быть только те программные решения, в которых актуализация данных является производственной необходимостью и происходит из дня в день. Решение должно включать в себя отлаженные алгоритмы, соответствовать самым последним нормативным актам, гарантировать всем участникам расчетов «игру по правилам».

↑ "Коммунальный комплекс России", № 9 (сентябрь) 2006, стр.38-39.

В основе заказной разработки ПО лежат специальные технологии

2010-04-27T15:10:15Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

Комментарий на статью Дмитрия Музалева «Корпоративное ПО: заказ или тираж?»

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

Поскольку детальный анализ тоже потребовал бы написания целой статьи, а возможно и не одной, мы ограничимся некоторыми соображениями, основанными на опыте заказной разработки ПО, которой наша компания — CUSTIS (Заказные ИнформСистемы) http://www.custis.ru - занимается с момента ее основания в 1996 г.

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

Отличие заказного ПО от тиражного заключается в том, что программа изменяется под заказчика, а не наоборот. Это обеспечивается использованием особых инструментария разработки и технологий ведения проектов. Например, в заказных проектах используется инструментарий, обеспечивающий масштабирование не только по «железу и базовому софту», но и по бизнес-логике, что, вопреки утверждению автора статьи, нехарактерно для тиражных решений. Фактически такая разработка — тоже проект доработки, а не создания системы «с нуля», но стартовые позиции и затрачиваемые ресурсы совершенно иные, чем в случае тиражных систем.

Объективными показателями для сравнения проектов доработки тиражных или заказных систем выступают начальный объем программного кода и количество необходимых изменений в исходной системе.

Допустим, заказчика устраивает 70 %-80 % функционала тиражной ERP-системы. Чем обернется переделка 20 %-30 % интегрированной системы? При реализации уникальных бизнес-процессов в тиражной системе велик риск затронуть работу ее базовых механизмов. Тогда заказчик получит настолько уникальную версию, что ее развитие может быть не просто слишком дорого, но вообще невозможно.

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

Известно, что в процессе внедрения объем дополнительных пожеланий заказчика возрастает в среднем на 2-10 % в месяц. Риски, порождаемые бурными изменениями, — это не только усложнение, удорожающее каждый последующий шаг доработки системы, но и размывание ее концептуальной целостности. Гарантировать управление таким проектом будет не только управление процессом разработки, но и технология передачи знаний от разработчика заказчику. Тут мы согласимся с автором: у заказчика должна быть сильная ИТ-команда.

Развитие всех этих технологий является предметом постоянного внимания и инвестиций для компаний, занимающихся заказной разработкой ПО.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «В основе заказной разработки ПО лежат специальные технологии»

К теме информатизации единых расчетно-кассовых центров проявляют интерес не только представители власти, но и бизнес

2010-04-26T16:50:47Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор CUSTIS (Заказные ИнформСистемы).

Опубликовано на сайте CNews в обзоре «ИТ в органах государственной власти» в январе 2004 г.

О проектах использования ИТ в реформировании ЖКХ CNews.ru рассказал Владимир Рахтеенко, генеральный директор компании "CUSTIS (Заказные ИнформСистемы).

CNews.ru: У вашей компании уже есть опыт проведения ИТ-проектов в сфере ЖКХ. Каков был реальный эффект от внедрений систем расчетных центров в городах Нижегородской области?

Владимир Рахтеенко: Одно уточнение. Нашим проектам в сфере ЖКХ предшествовал опыт создания сложных учетно-аналитических систем для Банка России и коммерческих банков. То есть мы пришли в ЖКХ не с нуля. Именно благодаря опыту работы с банками мы смогли предложить коммунальному хозяйству расчетные системы с банковским уровнем качества, идет ли речь о производительности, надежности, безопасности или сложности расчетов.

Компания «Заказные ИнформСистемы» работает на рынке с 1996 г. В 2000 году мы получили заказ от одного из первых в России коммунальных расчетных центров — «Центра СБК» — на разработку программного обеспечения для расчета и учета платежей населения в Нижегородской области. Внедрения успешно прошли в двух городах — Сарове, бывший Арзамас-16, ядерный центр России, и Выксе, где находится крупный металлургический комбинат. Велись работы и в Арзамасе, но в последний момент проект был свернут по политическим мотивам. Кстати, это яркий пример того, что именно политическая поддержка городской администрации является ключевым фактором во всех проектах создания и автоматизации коммунальных билинговых центров.

Что нам удалось? Судите сами. С самого начала была поставлена амбициозная задача объединить в едином контуре все платежи населения. И в этом направлении удалось сделать многое. Результаты первых внедрений билинговой системы показали, что она является мощным инструментом повышения эффективности работы жилищно-коммунального хозяйства. Суммы платежей за жилищно-коммунальные услуги (ЖКУ) начисляются по дням, в квитанциях автоматически учитывается изменение набора оказанных услуг, тарифов, аварий (недопоставок) по услугам, все изменения по лицевым счетам, в том числе за прошлые периоды. Реализована возможность массовых перерасчетов, включая перерасчеты задним числом на произвольную глубину. Причем по всем расчетам граждане могут получать подробные разъяснения.

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

Теперь администрации городов в любой момент времени имеют актуальные данные о состоянии жилищно-коммунальной сферы, БТИ — о жилом фонде и аварийности коммунальных сетей, социальные службы — о бюджетных суммах, необходимых для социальной поддержки населения.

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

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

После успешной пробы сил в Нижегородской области, освоив новую предметную область, наша компания предложила рынку тиражируемую систему для коммунального билинга — программно-технологический комплекс (ПТК) «Радей».

CNews.ru: Недавно было объявлено о начале внедрения системы «Радей» в Саратове…

Владимир Рахтеенко: Действительно, дебют ПТК «Радей» состоялся в Саратове. Победив в открытом конкурсе, организованном городской администрацией летом 2002 г., мы выполнили предпроектное обследование, провели адаптацию и настройку программного обеспечения, обучили специалистов технического центра и в мае 2003 приступили к внедрению системы на базе «Единого расчетно-кассового центра (ЕРКЦ) г. Саратова».

К ноябрю 2003 года системой были охвачены три района, 362 тыс. граждан, более 40 поставщиков ЖКУ. Сбор платежей, наряду с кассовыми пунктами ЕРКЦ, осуществляют пять коммерческих банков, Сбербанк и почта. Поставщики услуг и администрация регулярно получают отчеты более 60 типов. Планируется, что к весне 2004 г. единая информационная система на базе ПТК «Радей» последовательно охватит все шесть районов города с населением 864 тыс. человек. Обслуживание граждан: прием платежей, заявлений, документов, разъяснительную работу — обеспечат более 70 кассовых и абонентских пунктов, соединенных с диспетчерским и расчетными пунктами через обычные и выделенные линии связи.

CNews.ru: Каковы отличия этого проекта, от тех, что были реализованы ранее?

Владимир Рахтеенко: Основное отличие проекта в Саратове — его масштабность: если население городов Нижегородской области, где мы выполняли первые проекты для ЖКХ, не превышает 100 тыс. человек, то численность жителей в Саратове приближается к 900 тысячам. Кроме того, для предыдущего заказчика создавалось только программное обеспечение, здесь же требовался полноценный программно-технологический комплекс и связанные с ним услуги, включая консалтинг и обучение. «Радей» — это не только автоматизация сбора платежей и работы управляющих компаний (ДЕЗ, ЖЭУ и т. п.). Главное — корректность расчетов и поддержание единой базы данных, содержащей информацию о лицевых счетах, услугах, тарифах, поставщиках, управляющих компаниях, сборщиках платежей и т. д.

Такая идеология системы позволяет на ее основе создать в крупном городе или области своего рода «ЦУП для ЖКХ» — центр учета финансовых, информационных и материальных потоков ЖКХ, гарантируя управляемость структурных изменений в отрасли при высокой коммерческой и бюджетной эффективности проекта.

Коммерческая эффективность проекта основана на аутсорсинге расчетной функции поставщиков услуг. Что это значит? Расчетный центр взимает плату с поставщиков за обслуживание лицевых счетов. Размер оплаты исчисляется в процентах от начислений или фиксированной суммой (n рублей в месяц за 1 лицевой счет). Поставщикам выгоден любой из вариантов, так как они фактически избавляются от большой статьи расходов на розничную сбытовую деятельность, от очередей в абонентских пунктах, от всей претензионной работы с населением и т. п.

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

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

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

С другой стороны, исчезают ситуации, когда люди не получают субсидии просто потому, что соцзащита вовремя не договорилась с поставщиками. Вовлечение в проект службы социальной защиты создает еще одну возможность. Это адресная социальная поддержка или так называемые персональные счета. Федеральное правительство и Госстрой уже второй год проводят эксперимент по внедрению адресных социальных счетов. Часть этого эксперимента — дополнительные субсидии из центра для населения тех городов и регионов, где есть расчетные центры и система адресных счетов. В прошлом году выделялось 5 млрд рублей на 8 регионов, но больше половины этих денег не было переведено на места просто потому, что там были не готовы к их учету и распределению.

CNews.ru: Сколько может стоить для города создание такой системы?

Владимир Рахтеенко: Естественно, цена билинговой системы для города это вопрос далеко не последний. Известно, что возможности ЖКХ невелики, что налоговая база муниципалитетов сокращается, возможностей для финансирования сложных проектов становится меньше. Это с одной стороны. С другой стороны, проект автоматизации расчетно-кассового центра стоит даже не в разы, а на порядки меньше, чем любой другой инфраструктурный проект, будь то ремонт тепловых сетей или массовая установка приборов учета. И, самое главное, единый расчетно-кассовый центр с промышленным билингом дает исчерпывающую информацию для детального анализа перспектив любого другого инвестиционного проекта в ЖКХ.

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

CNews.ru: А можно уточнить, что собою представляют эти расчетные или расчетно-кассовые центры. Это государственные, муниципальные предприятия или частные компании? Их деятельность как-то регламентирована законом?

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

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

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

Что касается законодательного регулирования, то есть Постановление Правительства РФ от 17.11.2001 № 797 о подпрограмме «Реформирование и модернизация жилищно-коммунального комплекса Российской Федерации» в составе федеральной целевой программы «Жилище». Но в целом нормативное регулирование РКЦ — это непаханое поле. Множество вопросов до сих пор решаются, что называется, ad hoc — индивидуально, случайным образом. Мы оказываем посильную консультационную поддержку заказчикам, например, знакомим с опытом других регионов. Однако множество вопросов, таких как условия взаимодействия РКЦ со службой социальной защиты, с органами управления и многие другие еще предстоит решать на всех уровнях законодательной власти.

CNews.ru: Каковы, по-вашему, основные риски проектов автоматизации ЖКХ?

Владимир Рахтеенко: Не знаю как для ЖКХ в целом, но при автоматизации единых расчетно-кассовых центров актуальны риски различных типов.

Во-первых, риски политические. Мы уже вскользь упомянули об этом, но нелишне повторить: четкая позиция региональной и местной власти является главным фактором успеха. Это значит, в частности, что поддержка проекта должна быть гарантирована на протяжении всего периода внедрения, который составляет от полугода до года, а с учетом предварительных организационных мероприятий — до двух лет.

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

Третий риск — технический персонал. К сожалению, квалифицированные программисты и системные администраторы встречаются в ЖКХ крайне редко, а уж специалисты по технологиям Oracle (лежащим в основе наших информационных систем) — тем более. Так что нам приходится совместно с заказчиком «выращивать» местный технический центр, подбирать кадры, проводить обучение, готовить людей к дальнейшему обучению пользователей, к оперативному сопровождению системы и развитию отчетности.

Четвертый риск связан с качеством тех информационных фондов, которые обычно существуют в городе до внедрения системы. Как правило, это очень «замусоренные» данные. Работа местных программистов редко оплачивается на рыночном уровне, изменения в программах производятся бессистемно, появляется много «подпорок», много временных и случайных решений. Кроме того, в подавляющем большинстве случаев старые программы городских вычислительных центров не сопровождаются даже технической документацией, а о схемах бизнес-процессов нечего и говорить. Так вот, все эти информационные завалы приходится расчищать, потому что выверка расчетов с населением, выверка долгов — это не только техническая проблема, но и большой социально-политический риск. Представляете, что будет, если в городе-миллионщике хотя бы 5 % населения не согласится с новыми квитанциями и придет за разъяснениями на абонентские пункты? Риск весьма неприятный, но мы умеем его предотвращать.

CNews.ru: Спасибо.

Репликация: База Знаний «Заказных Информ Систем» → «К теме информатизации единых расчетно-кассовых центров проявляют интерес не только представители власти, но и бизнес»

Хотя бы на полшага быть впереди своих конкурентов

2010-04-26T16:02:14Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор CUSTIS («Заказные ИнформСистемы»)

Опубликовано в журнале «Рынок ценных бумаг. Биржевое обозрение» № 2(4), 2004.

Свою оценку рынка программного обеспечения, а также проблем автоматизации бизнес-процессов дает Генеральный директор компании CUSTIS (Заказные ИнформСистемы) Владимир Рахтеенко. Беседу ведет Владимир Чванов.

В. Ч. Уважаемый Владимир Евгеньевич, большое спасибо за согласие дать интервью. Не могли бы Вы для начала немного рассказать о своей компании?

В. Р. Компания «Заказные ИнформСистемы» создана в 1996 г. Мы разрабатываем и внедряем программные комплексы, позволяющие специалистам в различных областяхэффективно решать сложные профессиональные задачи. Кредо нашей компании: система для клиента, а не клиент для системы. При создании программных комплексов используются мощные инструментальные системы CustIS, составляющие наше «ноу-хау». Основывая свои решения на программных продуктах лидеров мирового рынка, компания является участником партнерских программ корпораций Oracle и Microsoft.

Основные направления нашей деятельности — это автоматизиро анные системы для банков и финансовых институтов (учетно-аналитическая банковская система, бэк-офис фондового рынка, системы для дилинга и ипотеки), корпоративные информационные системы, комплексная автоматизация в сфере ЖКХ (ПТК «Радей»), системы анализа и управления знаниями для крупных компаний и холдингов, IT-консалтинг.

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

Нашими крупнейшими клиентами являются Центральный аппарат Банка России, АБ «СОБИНБАНК», КБ «Международный Банк Развития», Торговый холдинг «Спортмастер», Группа компаний «Юниделл», МУП «Единый расчетно-кассовый центр г. Саратова», ООО «Центр-СБК» (расчетная компания ЖКХ Нижегородской области). О проектах нашей компании можно узнать на Интернет-сайте http://www.custis.ru.

В. Ч. Формула позиционирования вашей компании на рынке звучит в ее названии: «Заказные ИнформСистемы». Этим вы заявляете, что беретесь за автоматизацию бизнес-процессов любого направления и любой сложности, не исключая выход за рамки финансового рынка? Стратегия работы «под заказ» —смелая, если не сказать рискованная. Чем она мотивирована и чем обеспечена?

В. Р. Хотя за восемь лет работы на рынке у нас накопился значительный опыт решения различных задач, но он охватывает далеко не все направления и бизнес-процессы финансового сектора. Наш конек — учет, accounting в самом широком смысле слова. В основе большинства наших проектов лежат разработанные компанией базовые технологии CustIS (Кастис). Это учетные технологии. Они позволяют создавать производительные учетно-аналитические системы для бэк-офиса, бухгалтерии и высшего руководства заказчика. Конечно, у нас есть нетривиальные решения для отдельных фронт-офисных задач — ипотечное кредитование, дилинговые операции. Но своим главным достижением мы считаем именно учетные машины.

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

Главный мотив приобретения финансовой компанией системы автоматизации бэк-офиса — снижение финансовых рисков. А наша задача — своим опытом и профессионализмом обеспечить гарантии этой надежности. Вот в этом смысле наша стратегия работы «под заказ» — не рискованная стратегия, а стратегия минимизации рисков. Причем рисков и заказчика, и наших. И спрос на нее есть. Иное дело, что сложно оценить его объем. Это связано с ограниченной прозрачностью рынка в целом.

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

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

Сложнее другое. Допустим, для тиражных решений еще можно достоверно описать функциональность, на основе прецедентов обозначить сроки, указать цену лицензий и ориентировочно цену внедрения. А как быть с заказной разработкой? Ведь если систему делают под «заказ», то ее как таковой еще нет. Функционал и сроки заранее неизвестны, а цена может быть названа лишь в первом приближении.

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

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

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

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

В. Р. Мне представляется, что обзоры банковского ПО сильно отличаются от обзоров IT-услуг для других финансовых институтов: банковская деятельность сильно зарегулирована, рынок АБС по многим признакам можно считать зрелым, устоявшимся. Боюсь, что может пройти еще много времени, прежде чем аналитики смогут предложить достаточно полные и методически выверенные обзоры по новым сегментам, пока инвестиционные компании, страховые агентства, пенсионные, паевые фонды и т. п. осознают, какая информация от них требуется и зачем это нужно им самим.

В. Ч. Стоимость систем автоматизации, например бэк-офиса, предлагаемых различными компаниями, колеблется в пределах от тысячи до сотни тысяч долларов. Чем объясняется такой значительный разброс?

В. Р. Разброс цен объясняется разным масштабом задач и разным уровнем понимания рисков автоматизации. Если, скажем, коммерческий банк восстанавливает работу фондового подразделения, то ему нужно сделать это быстро и дешево. Здесь подойдет простое тиражное решение, без серьезной интеграции с другими приложениями, без развитой аналитики.

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

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

В. Ч. Можно ли, используя ранжирование финансовых компаний по числу сделок и IT-компаний по стоимости разработок, установить, «кто чей клиент»?

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

В. Ч. Доля использования банками собственных разработок в автоматизации различных операций составляет 15—35 %. Последнее значение относится к автоматизации операций на фондовом рынке. А для инвестиционных компаний этот показатель еще выше. Не является ли эта сфера своеобразным Клондайком будущих внедрений? Каково Ваше отношение к собственным разработкам?

В. Р. Собственные разработки будут производиться еще долго. Где-то из соображений безопасности, где-то по инерции. Но их доля будет сокращаться. Это общая тенденция ПО на финансовом рынке. Большие IT-отделы в банках и финансовых организациях уходят в прошлое. И не только потому, что содержать штат программистов дороже, чем купить систему на стороне. Кроме текущих расходов, есть еще инвестиции в развитие технологии и квалификацию персонала. Для собственных разработок, если только речь не идет о системах, создаваемых IT-отделами крупных отраслевых лидеров, характерно отсутствие «эффекта масштаба». Компании-разработчики ПО в каждый новый проект привносят опыт и технологии, наработанные ими в проектах не только на аналогичном, но и на других рынках.

Типичная проблема собственных разработок — отсутствие нормальной документации. Все знания — в голове одного или нескольких сотрудников. Если они увольняются, то система повисает в воздухе. А сильный разработчик или поставщик системы обязательно обеспечит заказчику и документацию, и «горячую линию» поддержки. Для работы на фондовом и валютном рынках это очень важно.

В. Ч. Не является ли вторым внушительным ресурсом автоматизации деятельность паевых инвестиционных фондов, интенсивно стимулируемая пенсионной реформой?

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

В. Ч. Рынок программного обеспечения — вторичный рынок. Каковы Ваши прогнозы в отношении его развития в 2004 г.?

В. Р. Рост рынка ПО для финансистов в 2004 г. будет ограничен в основном одним фактором — производительностью разработчиков и проектных команд. Чем больше масштаб задач и размер системы, тем сложнее технологии и соответственно выше требования к проектной команде. Это означает, что проектная команда не может расти прямо пропорционально сумме договора, как по мановению волшебной палочки. Как это ни странно, но деньги не решают все. Даже если поставщик находит на рынке лучшие кадры и привлекает их лучшими условиями, требуются месяцы для того, чтобы новые люди срослись с командой и начали работать как одно целое. Сейчас спрос опережает предложение. Это значит, что у всех нас будет много интересной, сложной и нужной работы.

В. Ч. Владимир Евгеньевич, спасибо за содержательное интервью. Желаем Вашей компании дальнейших успехов в разработке и продвижении на рынке нестандартного программного обеспечения и разделяем Ваше стремление «…хотя бы на полшага быть впереди своих конкурентов».

Репликация: База Знаний «Заказных Информ Систем» → «Хотя бы на полшага быть впереди своих конкурентов»

Knowledge Management: От Склада к Потоку (Software People-2010)

2010-04-24T19:41:08Z

StasFomin:

Выступление на конференции Software People-2010.

Докладчик: Стас Фомин

Hg-rebase-better-than-bzr-ithelps.sh

2010-04-22T16:58:02Z

BenderBot: 1 версия

#!/bin/sh
 
svnadmin create test
svn co file://`pwd`/test test-co
cd test-co
echo "helloworld" > a
echo "diepeople" > b
svn add a b
svn ci -m "add a+b to svn"
cd ..
hg clone file://`pwd`/test test-hg
cd test-co
echo "tretiynah" > c
svn add c
svn ci -m "add c to svn"
cd ..
cd test-hg
echo "rozoviyslonik" > d
hg add d
hg ci -m "add d to hg"
hg pull
hg merge
hg ci -m "merge to hg"
echo "1nah" > a
hg ci -m "change a in hg"
#hg push file://`pwd`/../test # ФИГВАМ! Sorry, can't find svn parent of a merge revision.
echo "5nah" > e
hg add e
hg ci -m "add e to hg"
hg rebase -d 2
hg push

Bzr-rebase-dont-help.sh

2010-04-22T16:58:02Z

BenderBot: 1 версия

#!/bin/sh
 
svnadmin create test
svn co file://`pwd`/test test-co
cd test-co
echo "helloworld" > a
echo "diepeople" > b
svn add a b
svn ci -m "add a+b to svn"
cd ..
bzr branch `pwd`/test test-bzr
cd test-co
echo "tretiynah" > c
svn add c
svn ci -m "add c to svn"
cd ..
cd test-bzr
echo "rozoviyslonik" > d
bzr add d
bzr ci -m "add d to bzr"
bzr merge
bzr ci -m "merge to bzr"
echo "1nah" > a
bzr ci -m "change a in bzr"
bzr push `pwd`/../test # ФИГВАМ! Operation denied because it would change the mainline history. (логично)
bzr rebase -r 5 # ФИГВАМ! No revisions to rebase.
bzr rebase --onto=2.1.1 # ФИГВАМ! ERROR: exceptions.AttributeError: 'NoneType' object has no attribute 'get_known_graph_ancestry' а дальше идёт Python traceback
bzr rebase -r 2 # Проходит, но изменения, внесённые в bzr, пропадают бесследно и проносить в svn становится нечего.

Решение CUSTIS: информационная система для торговых компаний с уникальными бизнес-процессами

2010-04-22T10:58:30Z

BenderBot: 1 версия

Категория:CUSTIS (Заказные ИнформСистемы)

Публикация на сайте TAdviser в обзоре «ERP в торговле 2007» (июнь 2007)

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

Специфика заказных проектов разработки ПО такова, что требует от компании-разработчика постоянного отслеживания и внедрения у себя новых технологий — как собственно разработки ПО, так и ведения проектов. В результате заказчик получает решение на основе современных ИТ, гибкое и модифицируемое.

Информационная система CUSTIS для торгового предприятия, основанная на современных технологиях, успешно решает такие задачи быстрорастущего бизнеса, как:

Масштабирование бизнеса — по обороту и территории
Сохранение контроля и управляемости при росте масштабов бизнеса
Быстрое расширение спектра предложений и услуг для оптовых и розничных клиентов
Оперативное взаимодействие между различными подразделениями (головным офисом, магазинами, логистическими службами, складами, и др.)

Для оптовых и розничных торговых сетей компания «Заказные ИнформСистемы» предлагает набор программных компонентов для автоматизации наиболее сложных, ресурсоемких и динамичных бизнес-процессов:

Каталог товаров
Управление товарным запасом
Снабжение пунктов розничной торговли
Розничный магазин
Оптовые продажи
Аналитическое хранилище

Компоненты информационной системы CustIS могут устанавливаться и работать в торговом предприятии в различных конфигурациях. Взаимодействие между модулями осуществляется по согласованному API. Взаимодействие со сторонним ПО также может осуществляется по API.

(В разное время, начиная с осени 2003 г., перечисленные программные компоненты ИС были внедрены и работают в торговой сети «Спортмастер»)

Внедрение модуля «Розничный магазин» CustIS в торговой сети «Спортмастер»

2010-04-22T10:58:15Z

BenderBot: 1 версия

Категория:CUSTIS (Заказные ИнформСистемы)

Публикация на сайте TAdviser в обзоре «ERP в торговле 2007» (июнь 2007)

С августа 2006 г. в Москве в магазине торговой сети «Спортмастер» на Рублевском шоссе, д. 62 работает модуль «Розничный магазин», разработанный компанией «Заказные ИнформСистемы» (http://www.custis.ru/). Создание и внедрение модуля «Розничный магазин» стало очередным этапом в развитии корпоративной информационной системы «Спортмастер».

Важное преимущество заказной разработки – способность развиваться в разнородной информационной среде

2010-04-21T16:32:46Z

BenderBot: 1 версия

Михаил Заборов, руководитель направления Торговые сети

компании CustIS (Заказные ИнформСистемы)

Андрей Борейко, заместитель директора по развитию бизнеса компании CustIS (Заказные ИнформСистемы)

Обзор на сайте CNews «ИТ в торговле 2007» ^[1].

О тенденциях и подходах к использованию торговыми сетями заказных ИТ-решений.

CNews: Как вы оцениваете современное соотношение спроса ритейлеров на заказные разработки и коробочные решения? Как этот спрос изменился по сравнению с ситуацией 2-3 летней давности?

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

Если говорить о рынке решений для ритейла, то сейчас, в отличие от ситуации 2-3 летней давности, подтягивается вторая волна розничных сетей, которая предъявляет платежеспособный спрос на все виды разработки, то есть осваивает разные подходы к автоматизации. Мы видим спрос со стороны крупных региональных сетей. Мы видим спрос среди тех сетей, в которых собственники сохраняют непосредственный контроль над управлением и пока не собираются продавать свой бизнес. Для этих компаний выбор модели взаимодействия с поставщиком решения — вопрос во многом открытый, так как для них создание информационной системы все еще является одним из инструментов долгосрочного развития, а не частью предпродажной подготовки.

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

Андрей Борейко: Прежде всего надо заметить, что заказная или проектная разработка принципиально отличается от «домашней». Различия существуют, прежде всего, на уровне подхода. Внутренняя разработка — это вспомогательный бизнес-процесс, который практически всегда имеет меньший приоритет, чем основная — торговая или производственная — деятельность. А заказная разработка — это профессиональная деятельность, профессиональная услуга. Клиент может мириться с ошибками собственной ИT-службы, принимая во внимание ее относительно меньшую стоимость. К внешнему подрядчику предъявляются совершенно другие требования. Отсюда следуют различия в темпах обновления технологической базы, в требованиях к рядовым специалистам, к методике управления проектами и так далее. От внутренней разработки ожидается, что ПО будет работоспособно. От заказного решения требуется предъявить все атрибуты промышленного ПО. Кроме живого кода должна быть документация, программа обучения, выделенная служба поддержки и так далее.

CNews: С кем вам приходится конкурировать больше — с внутренней разработкой или с готовыми решениями?

Андрей Борейко: У клиента, как известно, есть три возможности — не предпринимать ничего, разрабатывать ПО самостоятельно или купить готовое решение. Мы предлагаем четвертую возможность. Заказная разработка может сосуществовать с внутренними и готовыми решениями, но все они вместе взятые конкурируют с инерционным сценарием развития предприятия, без инвестиций в IT.

CNews: Как вам удается сосуществовать с внутренней разработкой у клиента?

Михаил Заборов: Очень хорошо удается. Вообще наличие сильной ИT-службы внутри клиента — большая удача. Вот у «Спортмастера» просто потрясающая айтишная команда. Ее вклад в развитие сети невозможно переоценить. Имея такую ИT-службу, можно эффективно управлять работой и внешних проектных команд и поставщиков готовых решений.

К сожалению, далеко не все торговые сети вкладываются в развитие собственных команд так, как это делает «Спортмастер». И дело здесь не только в экономии и в абсолютных размерах торговой сети. Просто так складываются приоритеты, что даже при сопоставимых оборотах сети численность технологических подразделений может различаться в разы, если не на порядки.

CNews: Поставщики готовых решений, считается, предлагают клиенту нечто осязаемое, что нужно только адаптировать, немного доработать. А на какой базис опирается заказное решение? Не слишком ли накладно и рискованно для клиента начинать разработку «с нуля»?

Михаил Заборов: Начинать «с нуля» имеет смысл в случае действительно уникальных бизнес-процессов. Например, в абсолютно новой предметной области. Более того, в таком случае другие варианты вообще не просматриваются.

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

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

CNews: Общепризнанно, что одним из ключевых преимуществ готовых решений является использование «лучших практик». Готовое решение аккумулирует в себе опыт множества пользователей. Очевидно, заказной разработке трудно похвастаться таким багажом. Что она может противопоставить «лучшим практикам» от международных вендоров?

Михаил Заборов: Давайте разберемся, что такое «лучшие практики». Почему они лучшие? Ответ обычно такой: потому что до вас их использовали сотни компаний и никто не жаловался. Однако, такой подход хорош для тех, кто не претендует на лидирующие позиции. Для динамичных и амбициозных компаний это не оптимальное решение. Для них лучшие практики — это их собственные практики. Иначе они бы не были лидерами в своем сегменте.

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

CNews: Тем не менее, остается ценовой фактор: стоимость создания «готового ПО» распределяется среди большого числа клиентов. Можно ли считать, что в проектной разработке все бремя трудозатрат ложится на одного клиента?

Андрей Борейко: Все не так просто. Давайте посчитаем. Предположим, вы нашли готовое ПО, которое устраивает вас на 80 % (хотя такое совпадение — большая редкость). Нужно доработать всего 20 %. Сколько, по вашему, будет стоить такая доработка? Плюс эти самые 20 %?

Смотрите, инвестиции в разработку тех 80 % делались в расчете на большое число клиентов. Например, на 100 компаний. Стоимость разработки была распределена в среднем из расчета 0,8 % на одну компанию. А тут надо реализовать 20 % в расчете на одну компанию. То есть «удельный вес» нового функционала для разработчика в 25 раз больше, чем «вес» базовой конфигурации. Причем, далеко не всегда можно уверенно спрогнозировать что весь дополнительный функционал пригодится другим клиентам. Это грубый расчет — для наглядности. В действительности рост стоимости доработок происходит более плавно. Но в итоге природу не обманешь. Вот почему доработка вроде бы готовых решений пожирает иногда так много времени и ресурсов.

CNews: Допустим, что в каких-то специальных случаях разработка на заказ обойдется дешевле просто потому, что готовая ERP-система не покрывает узкую функциональную область. Но ведь в целом, так сказать, «по площади» готовые ERP-системы охватывают большинство бизнес-процессов?

Михаил Заборов: Формально это так.

Андрей Борейко: Слово «формально» означает, что система будет закрывать «по площади» все основные бизнес-процессы. Таковы требования стандарта или маркетинговой идеологии ERP. Но при этом некоторые бизнес-процессы будут реализованы лишь контурно. А другие будут реализованы строго определенным образом, который отличается от бизнес-процессов заказчика. И те и другие особенности не очень заметны на уровне презентаций.

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

CNews: По вашему мнению, фактически внедренная функциональность системы всегда отличается от декларируемой?

Михаил Заборов: Не всегда. Степень совпадения будет зависеть минимум от двух ключевых факторов. От наличия собственной ИT-экспертизы и от готовности менять свои бизнес-процессы. Если есть и то и другое, то результат может соответствует заявленным возможностям и ожиданиям: хотели внедрить систему Х — вот она, пожалуйста. Если ИT-экспертиза отсутствует и меняться не хочется, то решение будет внедрено в лучшем случае формально, для «галочки». Если отсутствует только одно из условий, тогда возможны два варианта. При отсутствии ИT-экспертизы многое будет зависеть от того, как повезет с подрядчиком. Повезет — внедрят, а не повезет — опять таки будет результат только на бумаге. Если же внутри есть хорошая айтишная команда, а бизнес-процессы руководство трогать не позволяет, то внедряют как бы систему Х, а на выходе получается заказное решение Y под брендом Х. Цена такого решения будет уже X плюс Y.

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

Андрей Борейко: То есть стихийная смена модели разработки оборачивается слабой управляемостью процесса. Поэтому неконтролируемый рост цены не сопровождается снижением рисков, а наоборот — риски растут пропорционально стоимости.

CNews: Допустим, что поскольку каждая модель разработки — внутренняя, готовое решение и заказное — имеет свои преимущества, готовые решения не вытеснят с рынка остальные подходы. Логично предположить, что выбор модели должен соответствовать определенным условиям. В каком случае какая модель разработки является оптимальной, скажем, для тех же торговых сетей?

Михаил Заборов: Надо учитывать на каком этапе развития находится торговая сеть. По нашим наблюдениям большинство сетей проходят максимум шесть этапов. Сразу оговорюсь, что последовательность этапов — не строгая. Они могут где-то совпадать или обгонять друг друга.

Первый этап — это, так сказать, маленький семейный бизнес. Многие проскакивают его и сразу переходят к следующему, второму этапу. Условно его можно назвать этапом «хирургической бригады». Это время, когда ответственность и полномочия начинают делегироваться от одного-двух лиц к более широкому кругу руководителей, появляется специализация. Именно на этом этапе закладываются собственные «лучшие практики», которые потом играют ключевую роль в развитии компании.

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

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

CNews: Подразумевается, что на первых трех этапах доминирует внутренняя разработка?

Михаил Заборов: Да. И это вполне оправдано. Но вот на четвертом этапе ситуация меняется. Его можно, опять таки условно, обозначить как этап «механизации». На этой стадии внедряются специальные, локальные приложения, которые слабо затрагивают сквозные процессы, но могут сильно повысить технологичность конкретных участков. Например, складская система (WMS), система управления транспортом (TMS).

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

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

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

CNews: При каких условиях выбор заказной разработки действительно оправдан?

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

Михаил Заборов: Заказной разработке предшествует концептуальное проектирование. Это очень важный этап, который, помимо прочего, позволяет согласовать с заказчиком жизненный цикл функциональных модулей, сопоставить объем инвестиций со сроком службы и ожидаемой отдачей на каждом участке автоматизации. При таком подходе мы избегаем и ловушки версионности. Ведь не секрет, что у готовых решений установка новой версии часто выливается в полномасштабный проект внедрения.

Еще одно очень важное преимущество заказной разработки — способность развиваться в разнородной информационная среде. При создании нового модуля на заказ проводится интеграция этого модуля с другими приложениями. И это неотъемлемая часть проекта. Нам случалось выполнять установку модулей в режиме «горячей замены», когда нужно запустить новое ПО в масштабах всей торговой сети за 2-3 часа. Причем все эти внешние, по отношению к новому ПО, приложения тоже находятся в состоянии развития. Это подвижная, «турбулентная» среда, в которой заказная разработка чувствует себя гораздо более уверенно, чем большинство готовых решений.

CNews: Каковы ближайшие планы вашей компании в развитии экспертизы в области автоматизации торговых компаний?

Михаил Заборов: Нам больше всего интересны те бизнес-процессы, которые характерны именно для сетевой торговли. Какие-то функции являются более стандартными и не требуют специальных отраслевых решений просто потому, что принципы управления этими функциями мало отличаются не только на разных предприятиях, но в разных отраслях.

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

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

Нас интересуют новые, как для нас, так и для наших клиентов, подходы и методики к организации бизнес-процессов, включая все уровни автоматизации: оперативный, тактический и стратегический. Но тактическому уровню я бы отдал приоритет.

CNews: Спасибо.

↑ [Обзор «ИТ в торговле 2007» http://www.cnews.ru/reviews/free/trade2007/index.shtml]

Testopia

2010-04-18T09:58:58Z

VitaliyFilippov:

Testopia — инструмент управления тест кейсами от Mozilla Foundation, тесно интегрированный в систему управления ошибками Bugzilla. Основной разработчик Greg Hendricks — инженер компании Novell, который видимо сопровождает их внешнюю инсталяцию Bugzilla и разрабатывает Testopia для нужд Novell. Он так же ведет блог посвященный Testopia.

Компании которые используют Testopia:

Novell — установлена Testopia, но она не показана наружу;

в ноябре 2006 тут шло обсуждение что надо выставить testopia для внешних тестировщиков, но не срослось

fedoraproject.org — рассматривали для использования, чем кончилось не ясно.

Есть PHP блиотека для доступа к функция XML-RPC Testopia http://idea.opensuse.org/content/ideas/develop-php-library-for-testopia-api.

Свободные системы, спасающие разработчиков (РИТ-2010)

2010-04-16T18:43:07Z

StasFomin:

Выступление Стаса Фомина на конференции «РИТ-2010».

Презентация-трансформер: S5 на MediaWiki

2010-04-13T21:36:03Z

PavelTrushin: Отмена правки 547253, сделанной участником PavelTrushin (обс.)

Slide Show

Warning: legacy <slide> parser hook used, change it to <slideshow> please

Заголовок: Презентация-трансформер: S5 на MediaWiki
Автор: Виталий Филиппов
Нижний колонтитул: Презентация-трансформер: S5 на MediaWiki
Дополнительный нижний колонтитул: Виталий Филиппов, 12:52, 29 июля 2020

Слайд

Почти все знают

«Смерть через PowerPoint»^{[1], [2]}

(©пасибо профессиональному «презентологу» Алексею Каптереву)

Слайд

«chicken chicken chicken»

(реакция будет та же)

Слайд

ну, чуть повеселее

Слайд

Почему так происходит?

Слайд

Люди гонятся за 2 зайцами!

Слайд

Ибо презентация — это:

Слайд

И демонстрация, …

Слайд

…и самостоятельное чтение

Слайд

УЖ + ЁЖ = ???

Слайд

Гуру говорят нам:

Garr Reynolds [3] [4], Guy Kawasaki, Алексей Каптерев, Nancy Duarte, TED…

Слайд ГУРУ

1 мысль (умная)
1 картинка (красивая)
1 график (простой)

…

Слайд

«Больше всё равно не поймут»

Слайд

⇒

Слайд

(гипножаба [5])

Слайд

Гипножаба-Style

Отличные «продажные» презентации

Слайд НО

Совершенно нечитаемые!
После показа — умирают!

Слайд

Мы — разработчики.

Презентации нам нужны для:

Учебных курсов
Демонстраций
Обсуждений

Слайд

Нужны ЧАСТО и reuseabельно.

Слайд

→ «Все блюда из MediaWiki!»

Слайд

S⁵

Слайд

A Simple Standards-Based Slide Show System

http://meyerweb.com/eric/tools/s5/

Слайд

Чистый HTML+JS.

Кроссбраузерный.

Слайд

∀ статья → презентация.

<slide style="custis" scaled="true" headingmark="Слайд">
;author: Виталий Филиппов
;subfooter: Привет всем!
</slide>

Слайд Шаблоны и стили

custis	default	blue

flower	yatil	pixel

Слайд Вставка кода

<code-java>...</code-java>

Обход коллекции

Collection<String> strings = new ArrayList<String>();
for (String item : strings) {
    System.out.println(item);
}
…
Iterator<String> it = strings.iterator();
while (it.hasNext()) {
    String string = it.next();
}

порядок, в котором будут возвращаться элементы определяется реализацией (LinkedList, HashSet, …)

Слайд Mindmaps

[на всё окно][свернуть]

Слайд TeX

<m>
\hat{f}(\omega)=\frac{1}{\sqrt{2\pi}}\int
\limits_{-\infty}^{\infty}f(x)
e^{-ix\omega}\,dx
</m>

Слайд GnuPlot

	<plot> set xrange [16:34] set grid ytics set style fill solid 1.0 noborder set boxwidth 0.7 relative set title 'Топ Бездны' plot 'Хорошие.dat' with boxes lw 2, 'Отличные.dat' with boxes lw 2 DATASET Отличные … </plot>

<plot>
set xrange [16:34]
set grid ytics
set style fill solid 1.0 noborder
set boxwidth 0.7 relative
set title 'Топ Бездны'
plot 'Хорошие.dat' with boxes lw 2, 'Отличные.dat' with boxes lw 2
DATASET Отличные
…
 </plot>

Слайд Flash-видео

или даже видео с YouTube (см. Chicken Chicken)

[[Файл:WikiBookmarksDemo.flv|500px]]

Слайд

Вся мощь у ваших ног!

Слайд Всё-всё-всё

От простейшего до извратов

over 1600 расширений:
календари, опросы, UML, PDF, облака тегов

Слайд

Ибо MediaWiki

Слайд Live Preview

Слайд

Takahashi	Похоже на Такахаши. («Алексей Капранов. Как сделать презентацию за час до доклада»)

Слайд

НО

Кроссбраузерно
Богато фичами
Часть Базы Знаний

Google Notebook на MediaWiki

2010-04-13T21:35:55Z

VitaliyFilippov:

http://events.kapranoff.ru/proposals/22

Slide Show

Warning: legacy <slide> parser hook used, change it to <slideshow> please

Заголовок: Google Notebook на MediaWiki
Автор: Виталий Филиппов
Нижний колонтитул: Google Notebook на MediaWiki
Дополнительный нижний колонтитул: Виталий Филиппов, 17:53, 5 апреля 2012

S5 (MediaWiki)

2010-04-07T15:54:01Z

VitaliyFilippov: /* Создание собственных стилей */

S⁵ или просто S5 — кроссбраузерная система быстрого создания презентаций на чистом HTML+JavaScript. Название происходит от Simple Standards-based Slide Show System — 5 раз «S», или S⁵.

Нашими усилиями была прикручена к движку MediaWiki в виде расширения, исходные коды которого находятся в нашем SVN.

Расчетно-кассовые центры: проблемы и перспективы коммунального биллинга

2010-04-05T16:46:26Z

BenderBot: 1 версия

Владимир Рахтеенко: Генеральный директор CustIS (Заказные ИнформСистемы)
Андрей Борейко: заместитель директора по развитию бизнеса CustIS (Заказные ИнформСистемы)

Опубликовано в журнале "Коммунальный комплекс Подмосковья" №5/2007 (стр.9-10) ^[1]

Взаимоотношения городских расчетно-кассовых центров (РКЦ) и поставщиков жилищно- коммунальных услуг, а также перспективы коммунального биллинга — животрепещущие проблемы современного жилищно-коммунального комплекса.
Последние тенденции в сфере коммунального биллинга заключаются в настойчивом стремлении поставщиков услуг и ресурсов к созданию или развитию собственных абонентских служб. Более того, крупные поставщики и управляющие компании строят вполне серьезные планы по созданию собственных расчетных центров. Предполагается, что эти новые расчетные центры придут на смену существующим муниципальным ВЦ/РКЦ, а те, в свою очередь, отомрут, как уже отмирают во многих городах муниципальные поставщики ЖКУ.
Ситуация усугубляется тем, что с принятием нового Жилищного кодекса и последующих правительственных постановлений в организации учета и расчетов за ЖКУ произошли не очень обнадеживающие изменения. По большому счету, идеологи реформы не оставляют места для РКЦ как явления. Считается, что функции расчетных центров будут выполнять управляющие компании и сами поставщики. Но, как известно, свято место пусто не бывает, и скорее всего на смену существующим РКЦ придут структуры под другим именем, но с похожими или немного измененными функциями.
Складывается противоречивая ситуация, когда материальные коммунальные сети считаются не подлежащими приватизации и оставляются в собственности муниципалитетов, а нематериальная инфраструктура — базы данных, техническая и прочая информация, которая в конечном итоге служит для поддержки материальной базы и без которой немыслимы современные системы жизнеобеспечения, — оставляется на усмотрение хозяйствующих субъектов.
Однако в рамках настоящей статьи мы намеренны коснуться более узкого круга вопросов. А именно — рассмотреть те факторы, которые, на наш взгляд, определяют перспективы взаимоотношений поставщиков и управляющих компаний с расчетно-кассовыми центрами (РКЦ):

влияние на деятельность поставщиков и управляющих компаний начавшегося процесса

коммерциализации ЖКХ;

взаимоотношения РКЦ и собственных сбытовых компаний поставщиков;

риски поставщиков при организации сбыта их услуг через РКЦ.

↑ Коммунальный комплекс Подмосковья" №5/2007 (стр.9-10)

О быте, политике и ИТ

2010-03-29T16:04:27Z

BenderBot: 1 версия

Татьяна Лисина к.ф.-м.н., ведущий аналитик «Заказные ИнформСистемы» (CustIS)

Опубликовано в журнале CIO, № 1-2 (февраль) 2010 ^[1]

В материале журналиста Елены Некрасовой «О быте, политике и ИТ» специалисты нескольких ИТ-компаний обсуждают проблемы, которые возникают в процессе расчетов и сбора платы за оказанные жилищно-коммунальные услуги и доведения информации о расчетных механизмах до потребителей.
Публикуем ответы нашего участника дискуссии Татьяны Лисиной.

Тема внедрения информационных технологий в ЖКХ, столь популярная два-три года назад, сейчас выпала из обоймы наиболее обсуждаемых. Означает ли это, что задача информатизации отрасли оказалась не столь важной, как это представлялось?

Последнее время не слышно широковещательных призывов к внедрению информационных технологий в ЖКХ. Стихли фанфары, сопровождавшие выделение средств по одноименному национальному проекту, часть из которых предназначалась на информатизацию отрасли. Масштабных сдвигов, как и в программах под эгидой «Электронной России», не наблюдается.

Однако потребность в общегородских информационных ресурсах никуда не делась, скорее даже, увеличилась, поскольку старение жилого фонда ведет к росту аварийности жилищной инфраструктуры. В тех городах, где он есть, единый информационно-расчетный центр (ЕИРЦ) как никакая другая организация владеет информацией о состоянии сферы ЖКХ. Связано это со спецификой деятельности управляющих компаний и коммунальных предприятий — их работу контролирует все население целого города. Ведь граждане скрупулезно следит за правильностью начисления оплаты, данных о жилье и проживающих, тарифах, расходах ресурсов, авариях и перебоях в работе коммунальных служб. А претензии по начислению стекаются в ЕИРЦ, тем самым формируя актуальные данные в сфере ЖКХ.

Практика показывает, что ЕИРЦ может решать три задачи:

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

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

В соответствии с сегодняшними веяниями, третья задача также становится важной. В утвержденном распоряжением Правительства РФ от 17 декабря 2009 г. N 1993-р перечне услуг, предоставляемых в электронном виде учреждениями субъектов Российской Федерации и муниципальными учреждениями, есть и услуги в сфере ЖКХ. Среди них не только доступ к информации о порядке предоставления коммунальных услуг, но и выдача разнообразных документов и справок (единого жилищного документа, копии финансово-лицевого счета, выписки из домовой книги, карточки учета собственника жилого помещения, поэтажного плана и т. д.). Часть этих данных уже есть в ЕИРЦ, причем в систематизированном и актуальном виде. Добавить в базы данных ЕИРЦ недостающую информацию и формы необходимых отчетов намного проще, чем создавать новые муниципальные базы данных, наполнять их, сопровождать и администрировать. Заметим, что ЕИРЦ, в основном, — коммерческие структуры, значит, необходимо обеспечить правовую основу для передачи требуемой информации муниципалитетам, желательно, не безвозмездно, иначе возникает проблема рентабельности ЕИРЦ, которые и так не жируют. Но эта проблема не сравнима по своей сложности с проблемой консолидации данных от десятков и сотен небольших компаний, которые потом еще придется проверить на непротиворечивость, актуальность и достоверность.

Какие проблемы и риски возникают у ЕИРЦ (РКЦ, ЕРКЦ) при реализации процессов а)начисления, сбора, обработки и перечисления платы за жилищно-коммунальные услуги, б) сбора и обработки информации и предоставления ее участникам системы: поставщикам услуг, органам власти и другим организациям.

Главная проблема в последние годы — рейдерский захват бизнеса, оперирующего денежными потоками. Население у нас, в целом, законопослушное, особенно старшая возрастная группа, и этот источник денежных средств не зависит от стоимости нефти на мировых товарных биржах. Атаку банковского лобби 2006—2009 годов по легитимации приема платежей от граждан исключительно через банки, удалось отбить благодаря совпадению интересов ЕИРЦ и операторов платежных терминалов, но угроза поглощения успешных частных расчетных центров крупнейшими управляющими компаниями и поставщиками ресурсов по-прежнему велика.

Насколько остро сегодня стоит задача автоматизации расчетов и платежей в сфере ЖКХ, чем это обусловлено? Какие задачи, с точки зрения ИТ, стоят перед ЕИРЦ?

Нет задачи автоматизации расчетов и платежей в сфере ЖКХ для существующих ЕИРЦ. ЕИРЦ изначально использовали автоматизированные системы начисления и учета платежей, работающие с базами данных потребителей жилищно-коммунальных услуг. Проблемы новых ЕИРЦ — найти инвесторов и выбрать ПО, соответствующее масштабу будущих задач и требованиям законодательства, в частности, требованиям, установленным ППРФ 307 от 23 мая 2006 года о порядке предоставления коммунальных услуг и 152-ФЗ о персональных данных. Перед работающими ЕИРЦ стоит задача обновления ПО для соответствия указанной законодательной базе и расширения спектра услуг, в том числе путем предоставления их через Интернет.

В настоящее время первостепенными являются задачи выживания, тем самым сохранения высокотехнологичного бизнеса. Не секрет, что оптимизация затрат по-российски зачастую начинается с задержки оплаты услуг. Если у предприятия стоит вопрос: кому заплатить, поставщику воды, газа или расчетному центру, — ответ очевиден. И даже если вопрос стоит по-другому: заплатить своим сотрудникам или ЕИРЦ, — выбор предопределен практикой работы трудовых инспекций и налоговых органов, за кредиторскую задолженность перед контрагентами на административные комиссии еще никого не вызывали.

Сегодня одной из обсуждаемых тем стала тема «биллинга полного цикла». Что включает в себя это понятие?

С момента появления первых информационных систем в сфере начисления и учета коммунальных платежей существовало ровно два подхода: сбор платежей и «биллинг полного цикла». Биллинговая система полного цикла в ЖКХ — это система, которая, как минимум, объединяет в себе функции расчетной и платежной системы. То есть обеспечивает поддержку единой базы данных населения, жилищного фонда, услуг, нормативов расхода, тарифов и льгот (монетизированных или натуральных), выполняет регистрацию расхода ресурсов, позволяет выставлять счета на оплату, производить сбор, обработку и диспетчеризацию платежей, вести сальдо по финансово-лицевым счетам плательщиков, выпускать отчеты для всех заинтересованных сторон.

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

В последние год-два, в связи с изменениями в законодательстве и с приходом частного капитала, темпы изменений в отрасли ускорились, а специфика отдельных городов стала проявляться более отчетливо. Возможно ли в таких условиях внедрение «коробочных» решений для коммунального биллинга, которые давно присутствуют на рынке, или для каждого ЕИРЦ необходимо создание заказного решения, учитывающего особенности организации его деятельности?

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

Каким требованиям должно удовлетворять ИТ-решение, используемые для автоматизации биллинга ЖКУ?

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

Какой функционал должно включать данное решение? Какова, на Ваш взгляд, его оптимальная архитектура?

Современная система для ЕИРЦ — это информационно-расчетная система промышленного класса, которая объединяет в себе функции расчетной и платежной системы. Она обеспечивает поддержку единой городской базы данных населения, жилищного фонда, услуг, нормативов расхода, тарифов и льгот, хранит результаты расчетов и данные о платежах в течение заданного периода, не меньше периода исковой давности. В такой системе пользователи имеют возможность выполнять регистрацию расхода ресурсов, выставлять счета на оплату по расходу и по утвержденным нормативам/тарифам для каждой управляющей компании в разрезе поставщик-услуга, выполнять перерасчеты в случае аварии или изменении данных плательщика. В функциях платежного модуля системы — обработка, диспетчеризация данных о платежах для неограниченного числа управляющих компаний и поставщиков ресурсов. С точки зрения эффективности сбора платежей преимуществом является возможность взаимодействия с неограниченным числом каналов оплаты и платежных систем, как это сделано в биллинговой системе «Радей», разработанной нашей компанией. Наличие расчетного и платежного модуля в системе обеспечивает ведение сальдо расчетов плательщиков, дает возможность выпускать стандартные и специфические отчеты о начислениях, авариях, платежах, задолженности плательщиков для участников системы, а также сводную отчетность для муниципальных институтов по их запросу. Современное биллинговое решение для ЕИРЦ должно каждой группе заинтересованных лиц (поставщикам, плательщикам и муниципальным службам) предоставлять доступ через Интернет к их специфической/личной информации.

Какие этапы включает проект создания расчетной системы? На что Вы посоветуете обратить внимание заказчику в процессе реализации данного проекта?

По нашему опыту внедрения системы «Радей» в различных городах от миллионников до районных центров, главной проблемной особенностью реализации такого проекта является большое количество независимых участников бизнес-процессов разных юридических форм, включая бюрократические институты. Необходимое условие успешного бизнеса ЕИРЦ закладывается (или не закладывается) заказчиком еще на начальной стадии проекта. Это соблюдение баланса интересов всех участников — собственников бизнеса, управляющих компаний, поставщиков ресурсов, муниципальных институтов, которое должно быть зафиксировано на этапе заключения договоров. При этом следует обязательно учесть права интеллектуальной собственности на передаваемые в ЕИРЦ базы данных их владельцами-поставщиками и предусмотреть соблюдение прав граждан на конфиденциальность персональной информации. Необходимо до начала работы согласовать объемы обязательств ЕИРЦ по выпуску типовой отчетности для всех и по разработке специфической отчетности для отдельных участников проекта. Как нам представляется, самый трудоемкий этап внедрения готового решения — создание единой актуальной базы данных путем выверки разнородных баз данных поставщиков — участников. Еще одна проблема, часто упускаемая из виду — недостаточный уровень ИТ-грамотности будущих пользователей расчетно-платежной системы, что требует их обучения до начала работы, контроля и регулярной переподготовки в процессе работы.

Как изменяется процесс управления коммунальными платежами в результате внедрения ИТ-решения? Какие преимущества получает расчетная организация, органы исполнительной власти, поставщики и потребители ЖКУ в результате внедрения биллинговой системы?

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

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

Коммерческие организации, напротив, зачастую заинтересованы в отсутствии стороннего контроля, следствием чего бывает задержка средств на счетах (особенно в управляющих компаниях), сокрытие доходов, уменьшение налоговых отчислений. Мы знаем, что есть поставщики ресурсов, которые не начисляют оплату (и не платят налоги «по начислению», как полагается по закону) до оплаты расхода потребителями, мотивируя это отсутствием показаний приборов учета и невозможностью определения налоговой базы. Традиционно поставщики и управляющие компании предпочитают не раскрывать свои бизнес-процессы, не отдавать расчеты и ведение сальдо на аутсорсинг. Крупные поставщики-монополисты, для которых затраты на биллинг относительно невелики, обычно уже имеют в распоряжении ту или иную информационную систему. Они идут на внедрение современных промышленных решений для расчетных центров, как правило, либо по политическим соображениям руководства, либо повышая капитализацию перед IPO, и в последнем случае результат внедрения не слишком важен — достаточно факта покупки лицензии. Инвестиционную активность даже крупных управляющих компаний ограничивает годичный срок действия договора на управление многоквартирным домом в соответствии с Жилищным кодексом. Для небольших компаний промышленные информационные системы просто не по карману.

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

↑ CIO, № 1-2 (февраль) 2010, стр.54-59.

ЕИРЦ и биллинг полного цикла

2010-03-29T16:02:25Z

BenderBot: 1 версия

Татьяна Лисина к.ф.-м.н., ведущий аналитик «Заказные ИнформСистемы» (CustIS)

В подготовке статьи журналиста Елены Некрасовой «Чем живет город» использовались материалы специалистов нескольких ИТ-компаний. Публикуем ответы Татьяны Лисиной на вопросы журналиста.

Статья «Чем живет город» опубликована в журнале CIO, № 12 (декабрь) 2008 ^[1]

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

По мере реформирования ЖКХ потребность в общегородских информационных ресурсах только обостряется. Единый информационно-расчетный центр (ЕИРЦ) как никакая другая организация владеет информацией о состоянии сферы ЖКХ. Связано это с тем, что, во-первых, в базе данных ЕИРЦ объединены и структурированы данные по всему городу, во-вторых, население самостоятельно следит за правильностью начисления оплаты и требует исправления неверных данных о домохозяйстве (особенно, увеличивающих размер оплаты). Такая же отличная обратная связь наблюдается в ЕИРЦ и в части учета аварий, что, безусловно, повышает достоверность сведений об аварийности коммунальных сетей и о выпадающих доходах поставщиков для возмещения из бюджета, если они рассчитаны в ЕИРЦ, а не предоставлены самим поставщиком ресурсов. А регулярная сверка данных льготников с органами социальной защиты выполняет задачу перекрестной проверки сведений, полученных от граждан.

Практика показывает, что ЕИРЦ может решать три задачи:

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

Во многих городах информационная система по начислению оплаты за ЖКУ была первым реальным свидетельством наступления эпохи информационных технологий для населения. Муниципалитеты этих городов используют актуальную информацию ЕИРЦ для более эффективного исполнения их властных полномочий и социальных обязанностей.

Сегодня одной из обсуждаемых тем стала тема «биллинга полного цикла». Что включает в себя это понятие? '

С момента появления первых информационных систем в сфере учета коммунальных платежей существовало ровно два подхода: сбор платежей и «биллинг полного цикла». Биллинговая система полного цикла в ЖКХ — это система, которая, как минимум, объединяет в себе функции расчетной и платежной системы. То есть обеспечивает поддержку единой базы данных населения, жилищного фонда, услуг, тарифов и льгот, выполняет начисления, позволяет выставлять счета на оплату, производить сбор, обработку и диспетчеризацию платежей, вести сальдо по финансово-лицевым счетам плательщиков, выпускать отчеты для всех заинтересованных сторон.

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

Законодательством 2004—2006 гг. в области ЖКХ и банковской деятельности самые доходные функции ЕИРЦ — сбор и распределение платежей — оказались нелигитимными. Под угрозой оказался не только бизнес ЕИРЦ, но и информационная поддержка социальных функций муниципалитетов. К счастью, недавно эта коллизия получила свое законодательное разрешение: 1 октября 2008 г. Государственная Дума приняла в первом чтении измененную редакцию проекта Федерального закона «О деятельности по приему платежей физических лиц, осуществляемой платежными агентами». Таким образом, скоро прием в ЕИРЦ платежей от населения будет регулироваться отдельным законом.

ЕИРЦ, более двух лет находившиеся под угрозой разорения банками — их конкурентами в области приема платежей, смогут как прежде продолжать свою работу, осуществляя коммунальный биллинг полного цикла.

Цель коммунальной реформы — создание конкурентного рынка управляющих организаций. Каковы перспективы и основные направления развития ИТ-решений для ЕИРЦ с учетом курса на развитие управляющих организаций?

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

Неудовлетворенность субъектов рынка ЖКУ сегодняшним положением имеет вполне объективные основания.

Поставщики ЖКУ, естественно, тоже страдают от этого недоверия.

Для муниципалитетов есть дополнительный аргумент в пользу создания (использования) ЕИРЦ. В процессе создания множества новых управляющих организаций аутсорсинг расчетных услуг — это способ смягчить проблемы периода получения профессиональных навыков новыми управляющими компаниями. Никто, кроме ЕИРЦ, не сможет эффективно выполнить эту функцию. Конечно, при этом муниципальные власти должны быть уверены, что база данных плательщиков не пропадет в ЕИРЦ.

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

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

↑ CIO, № 12 (декабрь) 2008, http://offline.cio-world.ru/2008/79/393391/

Архитектор в Agile (встреча AgileRussia.ru 2010-03-24)

2010-03-29T15:52:40Z

StasFomin:

Собрание прошло успешно, хотя и несколько сумбурно — по всей компании пришлось собирать стулья, чтобы усадить всех желающих. В этот раз объявление о собрании было опубликовано на http://habrahabr.ru, оно вышло там «на главную» и получился «хабраэффект» зарегистрировалось более ста восьмидесяти человек.

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

В общем, были неудобства, к следующим встречам планируем сделать и кондиционеры, и два работающих проектора, и озвучивание зала микрофонами с колонками.

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

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

Переход без остановки (Невозможное возможно)

2010-03-26T12:31:48Z

Галина Цатурян: /* Невозможная задача */

Беспальчук Игорь: руководитель проектов компании CustIS (Заказные ИнформСистемы)

Здесь мы публикуем полную версию статьи. Её журнальная версия опубликована в Директор информационной службы (CIO.RU), № 2 (февраль) 2010, стр 21-23 ^[1]

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

↑ "Директор информационной службы (CIO.RU), № 2 (февраль) 2010, стр.21-23. http://www.osp.ru/cio/2010/02/13000987/

ListFeed (расширение MediaWiki)

2010-03-25T21:43:16Z

StasFomin:

ListFeed — расширение MediaWiki, позволяющее генерировать простые RSS-ленты из стандартных списков MediaWiki (нумерованных «#» и маркированных «*»).

Инструкции по установке и исходные коды можно увидеть на домашней странице расширения.

С помощью этого расширения практически любой список можно превратить в RSS-ленту.

Расширение добавляет два новых тега — <listfeed> и <endlistfeed />, а также функцию парсера {{#listfeedurl:Feed Name}}, которая возвращает URL RSS-ленты, сгенерированной расширением из списка с заданным именем. Расширение позволяет легко превратить любой маркированный или нумерованный Wiki-список в RSS-ленты, которая автоматически обновляется при обновлении статьи.

Каждый элемент списка становится отдельной записью ленты.

Заголовком записи становится первая строка текста элемента списка.
Текстом записи — всё остальное, если оно присутствует, и просто весь текст элемента списка, если нет.
Дата записи разбирается в соответствии с заданным регулярным выражением (см. ниже) и вырезается из заголовка.
Ссылкой записи становится первая ссылка в тексте, за исключением даты, так как в дате может присутствовать ссылка на автора, например, если используются стандартные подписи (~~~~). Если ссылок в тексте нет, используется ссылка на статью с уникальным якорем (anchor) для идентификации записи.
Автором записи становится первая ссылка в пространство имён [[Участник:]] из текста элемента списка, либо автор последней ревизии статьи.

Ленты идентифицируются по именам (<listfeed name="ИМЯ_ЛЕНТЫ">) и помещаются в один каталог, поэтому в пределах одной Wiki-системы две ленты с одинаковыми именами будут перезаписывать друг друга при каждом обновлении страницы. Описанием ленты служит любой Wiki-код, заключённый в тег <listfeed> — он преобразуется в HTML и включается в RSS-элемент <about>.

Чтобы начать использовать ListFeed, добавьте тег <listfeed> перед вашим списком:

<listfeed name="ИМЯ_ЛЕНТЫ" [ОПЦИИ]>
ОПИСАНИЕ_ЛЕНТЫ
</listfeed>

И тег <endlistfeed> после списка:

<endlistfeed />

Чтобы вставить ссылку на ленту в текст статьи, нужно использовать функцию парсера:

{{#listfeedurl:ИМЯ_ЛЕНТЫ}}

На данный момент доступны две опции, связанные с разбором дат элементов ленты.

Как выжить городскому расчетному центру

2010-03-25T16:56:15Z

BenderBot: 1 версия

Татьяна Лисина, к.ф.-м.н., ведущий аналитик «Заказные ИнформСистемы» (CustIS)

Опубликовано в журнале «Коммунальный комплекс России», № 2 (февраль) 2010 ^[1]

ЕИРЦ, оснащенный современной биллинговой системой, может стать основой «электронного муниципалитета».

↑ «Коммунальный комплекс России», № 2 (февраль) 2010, стр.68-70.

Лучше один раз увидеть

2010-03-19T15:09:46Z

BenderBot: 1 версия

Максим Цепков: главный архитектор компании CustIS (Заказные ИнформСистемы)

Опубликовано в журнале Intelligent Enterprise, № 2(февраль), 2010 ^[1]

Одна из наиболее насущных и сложных проблем для компании — получение качественной управленческой отчетности. Ее решение требует взаимодействия различных специалистов: топ-менеджеров, сотрудников планово‑экономического отдела, аналитиков, обеспечивающих постановку задач, и программистов. Для этих групп характерны большие различия в понятийном аппарате: финансово‑экономические категории непонятны разработчикам, и наоборот, особенности автоматизации процессов не осознаются бизнес‑специалистами. Аналитики же зачастую не обладают достаточными знаниями, чтобы в полной мере обеспечить передачу информации и решение вопросов.

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

↑ Intelligent Enterprise, № 2 (212), 22 февраля 2010 года

Test1

2010-03-19T12:31:23Z

Пресс-служба: Удалено содержимое страницы

AskTom in Moscow: отчет Дмитрия Подушко

2010-03-19T10:20:59Z

BenderBot: 1 версия

AskTom in Moscow: отчет Дмитрия Белобородова

2010-03-18T18:59:48Z

BenderBot: 1 версия

AskTom in Moscow: отчет Алексея Яблонского

2010-03-18T18:59:05Z

BenderBot: 1 версия

Тренинг Андрея Бибичева по «DDD» (2010-03-03)

2010-03-16T13:21:18Z

StasFomin:

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

2010-03-11T16:47:12Z

BenderBot: 1 версия

Аналитика московского образования

2010-03-09T15:08:36Z

Галина Цатурян: /* Этапы проекта */

Категория:Квитко Никита (Статьи) и соавторы

«Аналитика московского образования»^[1]

В июле 2009 г. компании «Заказные ИнформСистемы» (CustIS) и «Электронная школа» завершили совместный проект по разработке и пилотному внедрению автоматизированной информационной системы (АИС) «Аналитика образования» в Информационно-аналитическом центре (ИАЦ) Департамента образования г. Москвы.
Заказчиком выступила «Электронная школа» — системный интегратор, специализирующийся на решениях в сфере образования, а разработчиком программного обеспечения — «Заказные ИнформСистемы».

↑ Опубликовано в PCWeek, http://www.pcweek.ru/themes/detail.php?ID=120685

Путь к результативной автоматизации

2010-03-09T14:50:32Z

BenderBot: 1 версия

Максим Цепков: главный архитектор компании CustIS (Заказные ИнформСистемы)

Опубликовано в журнале «Директор информационной службы» №10-2009 ^[1].

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

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

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

Следует оценить реализацию бизнес-процессов компании в рамках системы. В результате должен быть получен список процессов, которые потребуют реинжиниринга. Необходимо также оценить объем требуемых изменений.

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

Рассмотрим каждый из этих шагов подробно и с примерами.

Оценивать бизнес-модели, а не функционал

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

Пример. Если торговая компания имеет несколько складов, важно определить конкретный склад отгрузки заказа клиента. В одних компаниях склад может быть известен заранее и зависеть от географического положения клиента или от вида товара. В других — определяется логистиками только на этапе исполнения заказа. В обоих случаях функциональное требование формулируется как «Поддержка нескольких складов». Однако если его реализация в конкретной системе подразумевает выбор склада сразу при создании заказа, а компания может определять склад только на этапе его исполнения, то этот функционал системы нельзя будет использовать.

Оценка системы на основе функционала приводит к ошибочному решению. Почему же она так распространена?

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

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

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

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

Получение бизнес-модели системы

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

Первая причина отсутствия описания бизнес-модели — его большая сложность.

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

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

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

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

Что входит в описание бизнес-модели

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

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

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

Получение бизнес-модели по публичным материалам

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

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

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

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

Получение бизнес-модели от поставщика

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

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

Другой способ — посещение компаний, в которых система уже эксплуатируется, для знакомства с реализацией их бизнес-процессов. Это часто проще для поставщика, чем выполнить моделирование конкретных бизнес-процессов, однако от заказчика требует умения сопоставлять и оценивать различные варианты бизнес-процессов: будет показана реализация бизнес-процессов другой компании, а не вашей.

Оценка бизнес-процессов компании в системе

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

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

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

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

В результате оценки все бизнес-процессы разбиваются по трем категориям:

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

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

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

План изменения бизнес-процессов

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

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

Обычно вырабатывается некоторое композитное решение, сочетающее несколько из предложенных альтернатив.

Далее приведено несколько примеров решения подобных задач, позволяющих компании приспособиться к системе.

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

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

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

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

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

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

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

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

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

Максим Цепков — главный архитектор компании «Заказные ИнформСистемы» (CustIS); M_Tsepkov@custis.ru

↑ «Путь к результативной автоматизации», Директор информационной службы, №10-2009 http://www.osp.ru/text/print/302/10361605.html

Репликация: База Знаний «Заказных Информ Систем» → «Путь к результативной автоматизации»

Невыносимая тяжесть монолитной КИС

2010-03-09T14:34:09Z

StasFomin:

Михаил Заборов: руководитель направления «Торговые сети» компании CustIS (Заказные ИнформСистемы)

Опубликовано в журнале Intelligent Enterprise (Корпоративные системы), № 13-14 (18 сентября) 2009

^[1]

↑ Intelligent Enterprise (Корпоративные системы), № 13-14 (18 сентября) 2009 http://www.iemag.ru/analitics/detail.php?ID=19595

ЗИС: Последние новости

2010-03-05T17:33:53Z

VitaliyFilippov: Защищена страница «ЗИС: Последние новости» ([edit=sysop] (бессрочно) [move=sysop] (бессрочно))

2010-04-24 Software People 2010

24 апреля 2010

Команда сотрудников CUSTIS 22-23 апреля 2010 приняла участие в конференции Software People 2010

Стас Фомин сделал там доклад «Knowledge Management: от Склада к Потоку» — подробности и видео в блоге команды CUSTIS.

Разместил Пресс-служба в События 27 апреля 2010 15:35 (GMT), нет комментариев.

2010-04-14 РИТ-2010

14 апреля 2010

12-14 апреля в конференц-холле «Инфопространство» прошла конференция РИТ++ /2010. Наши специалисты Стас Фомин и Виталий Филиппов сделали там доклады:

Свободные [веб]системы, спасающие разработчиков

ShowTeamWork — визуализация работы команды

Google Notebook на MediaWiki

Презентация-трансформер S5 на MediaWiki

В блоге команды CUSTIS подробности и видео презентации Стаса Фомина Свободные [веб]системы, спасающие разработчиков

Разместил Пресс-служба в События 20 апреля 2010 19:08 (GMT), нет комментариев.

2010-02-26 Директор информационной службы (CIO.RU)

26 февраля 2010

В журнале «Директор информационной службы» № 2-2010 опубликована статья Игоря Беспальчука, руководителя проектов компании CUSTIS («Заказные ИнформСистемы»), посвященная проекту реинжиниринга одной из функциональных подсистем ИС крупной торговой компании: «Переход без остановки».

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

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

Полный текст статьи Игоря Беспальчука "Переход без остановки (Невозможное возможно)"

Разместил Пресс-служба в Публикации 26 февраля 2010 16:57 (GMT), нет комментариев.

2010-02-22 Intelligent Enterprise

22 февраля 2010

В журнале Intelligent Enterprise, № 2/2010 опубликована статья главного аналитика компании CUSTIS Максима Цепкова «Лучше один раз увидеть»

Одна из наиболее насущных и сложных проблем для компании — получение качественной управленческой отчетности. Ее решение требует взаимодействия различных специалистов: топ-менеджеров, сотрудников планово‑экономического отдела, аналитиков, обеспечивающих постановку задач, и программистов. Для этих групп характерны большие различия в понятийном аппарате: финансово‑экономические категории непонятны разработчикам, и наоборот, особенности автоматизации процессов не осознаются бизнес‑специалистами. Аналитики же зачастую не обладают достаточными знаниями, чтобы в полной мере обеспечить передачу информации и решение вопросов.

Полный текст статьи Максима Цепкова "Лучше_один_раз_увидеть"

Разместил Пресс-служба в Публикации 22 февраля 2010 16:57 (GMT), нет комментариев.

2010-02-19 CIO (Компьютерра)

19 февраля 2010

В материале журналиста Елены Некрасовой «О быте, политике и ИТ», опубликованном в журнале CIO № 1-2/2010, специалисты нескольких ИТ-компаний обсуждают проблемы, которые возникают в процессе расчетов и сбора платы за оказанные жилищно-коммунальные услуги и доведения информации о расчетных механизмах до потребителей.

Публикуем ответы нашего участника дискуссии — Татьяны Лисиной, ведущего аналитика компании CUSTIS

Разместил Пресс-служба в Публикации 19 февраля 2010 16:57 (GMT), нет комментариев.

2010-02-15 Коммунальный комплекс России

15 февраля 2010

В журнале «Коммунальный комплекс России» № 2-2010 г. опубликована статья ведущего аналитика нашей компании Татьяны Лисиной

«Как выжить городскому расчетному центру».

ЕИРЦ, оснащенный современной биллинговой системой, может стать основой «электронного муниципалитета». Нам представляется, что в настоящее время сложились объективные условия для объединения всех сторон коммунального хозяйства вокруг муниципального информационного центра (МИЦ) на базе ЕИРЦ в интересах развития городского коммунального хозяйства.

При выборе программного обеспечения мы рекомендуем остановиться на современной промышленной системе биллинга полного цикла. Такие системы не только имеют разветвленную отчетность и широкую возможность произвольных выборок из баз данных, но и обеспечивают безопасность доступа и хранения данных. В случае создания муниципального информационного ресурса, основой которого служит актуальная база данных биллинговой системы ЕИРЦ, муниципалитет станет «электронным» не на словах, а на деле. И это будет действенным примером реальных инноваций.

Прочитать/распечатать статью Татьяны Лисиной «Как выжить городскому расчетному центру»

Разместил Пресс-служба в Публикации 17 февраля 2010 13:06 (GMT), нет комментариев.

2009-12-15 ARCHLabs'2009

15 декабря 2009

15 декабря 2009 г. в Москве прошла конференция архитекторов, проектировщиков и разработчиков ПО Arch Labs 2009.

10 человек из команды CUSTIS участвовали в ней в качестве слушателей, а руководитель направления «Торговые сети» Михаил Заборов выступил с докладом «Аналитические планы счетов как архитектурный артефакт».

Программа конференции Arch Labs 2009

Разместил Пресс-служба в События 15 декабря 2009 16:57 (GMT), нет комментариев.

2009-12-14 CIO (Компьютерра)

14 декабря 2009

В журнале CIO, № 10/2009 опубликован материал Елены Некрасовой «Перемены? К лучшему!» по теме: какими способами может быть преодолен разрыв между функционалом информационной системы и потребностями постоянно изменяющегося бизнеса. На вопросы журналиста отвечали представители нескольких ИТ-компаний, в том числе Владимир Рахтеенко, генеральный директор CustIS:

Бизнес и ИТ должны совместно поддерживать концептуальный проект информационной системы предприятия, который периодически пересматривается. Это своего рода генеральный план развития информационной системы с декомпозицией на модули первого уровня от состояния «как есть» к состоянию «как будет». Бизнес и ИТ должны вместе разрабатывать бизнес-модели. Именно это — залог качества моделей. Именно это — гарантия того, что адаптивные возможности, заложенные в модели, будут совпадать с направлением развития бизнеса.

Прочитать/распечатать ответы Владимира Рахтеенко

Разместил Пресс-служба в Публикации 14 декабря 2009 16:57 (GMT), нет комментариев.

2009-12-09 AgileDays'2009

9 декабря 2009

В среду 9 декабря 2009 г. команда из 30 специалистов CustIS приняла участие в конференции AgileDays'2009. В программе было два наших доклада:

Андрея Бибичева — «Обзор Feature-Driven Development и Domain-Driven Design»

Стаса Фомина — «Увидеть лес за деревьями».

В этом году Андрей Бибичев вошел в программный комитет, а компания CustIS выступила серебряным спонсором, обеспечивая приезд на конференцию одного из ключевых докладчиков — Артема Марченко (Nokia).

Подробности в блоге команды CustIS и на сайте конференции AgileDays'2009

Разместил Пресс-служба в События 9 декабря 2009 16:57 (GMT), нет комментариев.

2009-11-26 Семинар «Разработка Концепции ПО»

26 ноября 2009

В четверг 26 ноября 2009 г. в офисе CustIS прошел семинар сообщества системных аналитиков «Разработка Концепции ПО»: При выполнении проекта по разработке ПО почти всегда речь идет только о документе «техническое задание». Однако существует другой, не менее важный документ, предшествующий техническому заданию — это концепция.

Подробности в блоге команды CustIS

Разместил Пресс-служба в События 26 ноября 2009 16:57 (GMT), нет комментариев.

2009-11-23 Req Labs 2009

17 ноября 2009

17 ноября 2009 г. в Москве прошла первая конференция для бизнес- и системных аналитиков, посвященная работе с требованиями в ИТ-проектах Req Labs 2009. 11 специалистов компании Заказные ИнформСистемы (CustIS) участвовали в ней в качестве слушателей, а Стас Фомин сделал доклад «Mind Maps и их применение в контексте формулирования требований к ПО».

Программа конференции Req Labs 2009

Подробности выступления Стаса Фомина в блоге команды CustIS

Разместил Пресс-служба в События 23 ноября 2009 18:12 (GMT), нет комментариев.

2009-11-23 CEE-SECR 2009

27-29 октября 2009

27-29 октября 2009 г. 30 специалистов компании Заказные ИнформСистемы (CustIS) приняли участие в пятой ежегодной конференции «Разработка ПО 2009» (CEE-SECR 2009). В этом году в программе было представлено четыре наших доклада:

Андрей Бибичев — Проектирование больших информационных систем в Agile

Виталий Филиппов — Одежка для Subversion: ViewVC и SVN-Searcher

Станислав Фомин:

Собор или базар: системы контроля версий — централизованные или распределенные?
Управление тестами с Testopia — недостающее звено?

Программа банковского (27 окт.) и основных дней конференции (28-29 окт.) CEE-SECR 2009.

Подробности и презентации выступлений в блоге команды CustIS

Разместил Пресс-служба в События 23 ноября 2009 18:12 (GMT), нет комментариев.

2009-11-13

22 октября 2009

В июле 2009 г. компании Заказные ИнформСистемы и Электронная школа завершили совместный проект по разработке и пилотному внедрению автоматизированной информационной системы (АИС) «Аналитика образования» в Информационно-аналитическом центре (ИАЦ) Департамента образования г. Москвы. Заказчиком выступила компания Электронная школа — системный интегратор, специализирующийся на решениях в сфере образования, а разработчиком программного обеспечения — Заказные ИнформСистемы (CustIS).

В октябре 2009 состоялись две публикации об этом проекте. В еженедельнике PC Week/RE, №40/2009 в разделе бизнес-аналитика опубликована статья Аналитика московского образования.

На сайте Tadviser в открытом аналитическом обзоре «BI в России 2009» опубликовано развернутое описание АИС «Аналитика образования»: совместный проект компаний «Заказные ИнформСистемы» и «Электронная школа»

Информация о проекте «Аналитика образования» на сайте CustIS

Разместил Пресс-служба в Публикации 13 ноября 2009 18:36 (GMT), нет комментариев.

2009-10-30 Директор информационной службы (CIO.RU)

30 октября 2009

В журнале «Директор информационной службы» № 10-2009 г. в разделе «Эффективность ИТ» опубликована вторая статья главного архитектора нашей компании Максима Цепкова, посвященная вопросам эффективности внедрений ИТ-приложений: «Путь к результативной автоматизации».

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

Прочитать/распечатать статью Максима Цепкова «Путь к результативной автоматизации»

Разместил Пресс-служба в Публикации 30 октября 2009 16:57 (GMT), нет комментариев.

2009-10-14 HighLoad++

12-13 октября 2009

12-13 октября 2009 г. специалисты отделов технологического развития и системного администрирования компании Заказные ИнформСистемы (CustIS) — Алексей Алексеев, Николай Кривоносенко, Михаил Ларин, Дмитрий Морозов, Валентин Орлов, Виталий Филиппов и Стас Фомин — приняли участие в Конференции разработчиков высоконагруженных систем HighLoad++ 2009 которая прошла в Московском конференц-центре Инфопространство.

12 октября Виталий Филиппов, ведущий веб-программист отдела технологического развития, представил на конференции блиц-доклад на тему «PHP-разгон: серебряная пуля из автомата Комменца-Вальтера».

Подробности доклада Виталия Филиппова в блоге команды CustIS

Разместил Пресс-служба в События 14 октября 2009 16:40 (GMT), нет комментариев.

2009-10-13 Intelligent Enterprise

9 октября 2009

В журнале Intelligent Enterprise (Корпоративные системы), №13-14 (18 сентября) 2009 опубликована статья «Невыносимая тяжесть монолитной КИС». Автор — Михаил Заборов, руководитель направления «Торговые сети» компании Заказные ИнформСистемы.

Пока единая информационная система не сдерживает развития бизнес-процессов компании, она должна оставаться монолитной — все прочие решения будут гораздо менее эффективными. Но как только бизнес «упирается» в ограничения ИТ, необходимо, чтобы руководители осознавали объективную природу проблем, возникающих с их корпоративной информационной системой на определенном этапе.

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

Прочитать/распечатать статью Михаила Заборова "Невыносимая тяжесть монолитной КИС"

Разместил Пресс-служба в Публикации 13 октября 2009 16:27 (GMT), нет комментариев.

2009-10-09 Теория и практика Agile

16-19 сентября 2009

16-22 сентября 2009 г. в г. Киеве (Украина) прошла конференция Agile Eastern Europe (AgileEE) 2009, на которую собрались специалисты из 15 стран. Ведущие сотрудники компании Заказные ИнформСистемы (CustIS) — Андрей Бибичев, Игорь Беспальчук, Андрей Гущин, Елена Сомина и Виктор Яницкий — были в числе её активных участников.

Игорь Беспальчук получил диплом Certified Scrum Product Owner (CSPO), приняв 16-17 сентября участие в мастер-классе Робина Даймонда (Robin Dymond).

18 сентября Андрей Бибичев, руководитель отдела технологического развития CustIS и сертифицированный Scrum-мастер, представил на конференции доклад на тему «А какой у вас Agile: свежевыжатый или порошковый?».

Подробности выступления и презентация Андрея Бибичева в блоге команды CustIS.
Подробная программа конференции Agile Eastern Europe 2009.

Разместил Пресс-служба в События 9 октября 2009 15:04 (GMT), нет комментариев.

2009-09-15 Анонс

18-19 сентября 2009

18-19 сентября 2009 г. группа ведущих сотрудников компании Заказные ИнформСистемы (CustIS) — Андрей Бибичев, Игорь Беспальчук, Андрей Гущин, Елена Сомина и Виктор Яницкий — примет участие в конференции Agile Eastern Europe (AgileEE) 2009 которая пройдет в г. Киеве (Украина). Ожидается 300 участников из 15 стран.

18 сентября Андрей Бибичев, руководитель отдела технологического развития CustIS и сертифицированный Scrum-мастер, представит на конференции доклад на тему «А какой у вас Agile: свежевыжатый или порошковый?».

Подробная программа конференции Agile Eastern Europe 2009.

Разместил Пресс-служба в События 15 сентября 2009 13:14 (GMT), нет комментариев.

2009-09-10

весна-лето 2009

Весною и летом 2009 г. специалисты нашей компании выступали с репликами на актуальные темы, которые поднимала редакция журнала Intelligent Enterprise (Корпоративные системы).

«Берегите персонал» — так отозвался Сергей Тихомиров, руководитель направления «Финансовые институты» на статью «Управление проектами: время героев?» Игоря Костылева и Константина Зимина в IE#7(2009). Наиболее важным ресурсом в ИТ-проектах, безусловно, являются люди — персонал компании. С точки зрения подхода к персоналу кризис глобально ничего не изменил, он лишь гипертрофированно подчеркнул значимость квалификации и эффективности использования специалистов. Сейчас крайне важно сохранить те ресурсы, от которых действительно зависит успех проектов.

Статью Ольги Мельник и Константина Зимина «Интеграция — откладываем до лучших времен» в IE#8(2009) прокомментировал Михаил Заборов, руководитель направления Торговые сети: «Потребность в интеграции снижается, но есть исключения». Даже во время кризиса есть примеры, когда бизнес выбирает вариант максимально автоматизированной интеграции. Например, мы завершаем проект разработки нового модуля для управления товаропотоком розничной сети. Новый модуль встраивается в сложный ИТ-ландшафт и тесно интегрируется со многими компонентами ИС, разработанными и внедренными в разное время разными командами, — в том числе со старой системой управления товаропотоком, с системой управления мастер-данными, с системой управления внешней логистикой, с системой управления складом, с системой класса BI, с торговой системой розничных магазинов, учетной системой и бухгалтерией. Что обусловило такой широкий круг требований? У этой компании очень сильная ИТ-служба. Пользователи привыкли, что ИТ практически не ограничивает гибкости бизнес-процессов. Это порождает высокие требования к интеграции ПО.

На актуальную тему о лицензировании и использовании свободно распространяемого ПО, обсуждавшуюся в июньском номере IE#11(2009), откликнулся руководитель проекта Николай Кривоносенко: «Сокращения ИТ-бюджетов заставляют экономить». До кризиса многие компании вкладывались в легализацию ПО, но сокращения IT-бюджетов заставляют экономить. Отказ от покупки необходимого ПО чреват сбоями, а то и полной остановкой выстроенных бизнес-процессов. Встает дилемма: возвращаться в «историю» и подвергаться немалым юридическим рискам или использовать свободно распространяемое ПО, что также неоднозначно с точки зрения закона.

Разместил Пресс-служба в Публикации 10 сентября 2009 16:28 (GMT), нет комментариев.

2009-09-09 Директор информационной службы (CIO.RU)

22 июля 2009

В журнале «Директор информационной службы» №7-2009 г. в разделе «Эффективность ИТ» опубликована статья главного архитектора нашей компании Максима Цепкова: «Результативность автоматизации».

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

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

Прочитать/распечатать полную версию статьи Максима Цепкова

Разместил Пресс-служба в Публикации 9 сентября 2009 17:29 (GMT), нет комментариев.

SEG-2010 (отчет Стаса Фомина)

2010-03-03T23:51:23Z

VitaliyFilippov:

~~Прошлую неделю~~Неделю в феврале провел на мероприятии достаточно оригинального формата — гибриде конференции и отдыха. Называлось все это Software Engineering Gathering 2010 «…слёт специалистов в области инженерии ПО … любые темы, связанные с инженерией ПО… февраль, Египет…».

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

Ну, а это был более скорее более пляжный вариант, ибо Египет в самое свое холодное время, вполне купабелен и всяко теплее Москвы-Питера-Минска в самые свои теплые деньки^[1].

↑ Возможно доступная «пляжность» это таки баг, а не фича

MediaWiki — Серебряная пуля или швейцарский нож?

2010-02-11T19:23:18Z

StasFomin: /* Дополнения */

Стас Фомин: Заместитель директора по информационным технологиям / stas@custis.ru

«Mediawiki: Серебряная пуля или швейцарский нож?»^[1]

↑ Статья написана в июле 2008, к конференции SECR-2008, опубликована с сокращениями в «Открытые системы», апрель 2009

Управляемая ликвидация

2010-02-11T18:00:04Z

BenderBot: 1 версия

Михаил Заборов, руководитель направления Торговые сети компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), №12, 20 декабря 2008, стр. 22-25.

Рано или поздно унаследованное программное обеспечение приходится заменять. Как при замене избежать «провала» в функциональности, характерного для слабых внедрений? В какой момент можно безболезненно отказаться от унаследованных приложений? Необходимо продумать сценарий бережного внедрения нового и управляемой ликвидации старого программного обеспечения.

Когда заходит речь об унаследованных приложениях, то чаще всего подразумевается, что они были навязаны компании обстоятельствами. Возможно, это наследство предыдущего ИТ-руководства, и тот, кто выбирал это программное обеспечение, давно уже работает в другой компании. A может быть, оно досталось организации в результате процессов слияния и поглощения, или просто сложилось в ходе ее исторического развития. Хорошо, если унаследованное программное обеспечение вписывается в текущую ИТ-концепцию. Если же оно не адекватно ИТ-стратегии предприятия, то долго жить с ним, как с постоянной зубной болью, не получится. Проблему все равно придется решать (случаи самоизлечения зубов науке пока не известны).

Почему организации расстаются с унаследованным программное обеспечение? Причины могут быть разные:

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

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

Вечно жить с унаследованным приложением нельзя, но и одномоментно расстаться с ним невозможно. Ниже описывается один из возможных сценариев, позволяющих минимизировать ущерб для компании-заказчика при смене ИТ-системы.

Результативность автоматизации

2010-02-11T17:35:44Z

BenderBot: 1 версия

Максим Цепков: главный архитектор компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), № 7, 15 июля 2009, стр. 40-42.

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

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

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

Приступая к внедрению, необходимо тщательно продумать, какой вариант предпочтителен, определив, в частности, перечень бизнес-процессов, подлежащих автоматизации и возможному перепроектированию. Это даст возможность сохранить имеющиеся преимущества и приобрести новые. Ошибки на этом этапе реализации проекта внедрения приводят к неадекватной автоматизации, когда ряд функций основных бизнес — процессов получают недостаточную ИТ-поддержку или совсем ее не получают. В результате внедряемая система обрастает рядом вспомогательных приложений, «подпорок», что существенно усложняет и утяжеляет ИТ-ландшафт организации.

Проводники в джунглях системной сложности. Автоматизация ключевых бизнес-процессов крупных предприятий

2010-02-11T17:15:08Z

BenderBot: 1 версия

Владимир Рахтеенко: Генеральный директор CustIS (Заказные ИнформСистемы)

Журнал Intelligent Enterprise (Корпоративные системы), № 18, 24 ноября 2008, стр. 48-51. http://www.iemag.ru/analitics/detail.php?ID=18270&phrase_id=37452

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

Все гуру предпринимательства и менеджмента говорят: «Ищите отличия, усиливайте отличия, специализируйтесь, меняйтесь, развивайтесь», — а после внедрения от ИТ директоров мы слышим: «Ничего не трогайте и не меняйте, только тогда всё будет работать». Один мой знакомый управляющий в сердцах так описал чудовищный функциональный разрыв, который возникает в таких проектах: «Они (вендоры) берут свое маленькое квадратное ведро и одевают на нашу большую круглую голову!».

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

Восходящая «Звезда» MDM

2010-02-11T16:31:28Z

BenderBot: 1 версия

Валерий Никитин: аналитик проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Роман Алексеев: руководитель проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Михаил Заборов: руководитель направления «Торговые сети» компании «Заказные ИнформСистемы»

Журнальная версия статьи опубликована в «Директор информационной службы (CIO.RU)», №9 (сентябрь) 2008, стр.50-53.

Быстрые темпы развития ИС, предназначенных для ведения НСИ, не дают возможности разработчикам договориться о терминологии и разобраться во множестве существующих решений. Анализ рынка приводит к выводам о том, что российским компаниям для ведения НСИ больше других подходит модель «Звезда».

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

Термин «мастер-данные» является дословным переводом понятия «Master Data», которое также переводят как «основные данные». Эти данные, востребованы многими модулями и компонентами информационной системы. Высокая внутрисистемная значимость такой информации накладывает определенные ограничения на ее качество и, как следствие, на принципы работы с ней: о таких данных можно говорить, что они являются «эталонными», а модуль, который их производит, — единственно верным источником.

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

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

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

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

Управление тестами с Testopia — недостающее звено? (SECR-2009)

2010-01-27T20:24:58Z

StasFomin:

Продолжаем выкладывать материалы по нашим докладам с CEE-SECR-2009/SQALabs-6.

Публикуем доклад Стаса Фомина «Управление тестами с Testopia — недостающее звено?» (Test management with Testopia — missing link?)

Тема управляемого функционального тестирования не нова. Достигнуто единство концепций и методик — да, нужен учет требований и сценариев тестирования, результатов тестовых прогонов для каждой сборки продукта, нужно вести метрики, видеть покрытие тестированием требований заказчика, анализировать плотность найденных ошибок, вычислять проблемные места, управлять командой тестировщиков и демонстрировать процесс заказчику. И для этого нужна специализированная система для управления тестированием.
Однако, несмотря на этот консенсус, лишь очень малая часть компаний заводит такую систему. Причем тестирование-то идет, только управление тестированием идет с помощью совершенно неожиданных инструментов — электронных таблиц и текстовых процессоров, баг-трекеров, вики-систем и обычных систем контроля версий.
Мы рассмотрим, почему так происходит, на основе своего опыта внедрения нескольких test-management систем, и расскажем о нашем выборе — системе Testopia, которая «не берет на себя» лишнюю функциональность, оставляя ее более приспособленным инструментам, а интегрируется с некоторыми из них, заполняя потребность лишь в специфическом функционале.

Вернее мы публикуем не сам доклад на SECR/SQADays (ибо видеозаписи там не было), а часть внутреннего семинара по данной теме.

Итак, представляем двадцатиминутное видео самого доклада:

и короткий пятиминутный скринкаст самой системы (сорри, без озвучки, но вроде и так все понятно):

Если что-то на видео было неразборчиво — можно просмотреть слайды:

Слайды не «тезисные» (то есть не слайдоменты), и отдельно от видео выступления их рассматривать не очень эффективно.

Но можно и не смотреть видео — для разъяснения (и для предпочитающих чтение), прилагаем краткую статью.

Репликация: База Знаний «Заказных Информ Систем» → «Управление тестами с Testopia — недостающее звено? (SECR-2009)»

Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)

2010-01-27T20:24:15Z

StasFomin:

Итак, успешно прошла пятая по счету конференция SECR (в этом году она переименовалась в CEE-SECR 2009, но суть осталась прежней).

Мы совершенно не зря, рекомендовали наши доклады как нескучные — собственно по результатам зрительских симпатий на конференции наши доклады заняли второе и третье место.

Традиционно для SECR-2009 видеозапись и публикация докладов не велась, так что мы берем эту обязанность на себя и опубликуем все материалы по этим докладам — видео, слайды, статьи и т.п.

Первым у нас будет доклад Виталия Филиппова, «Одежка для Subversion: ViewVC и SVN-Searcher».

Во многих компаниях используется общеизвестная система управления версиями Subversion — бесплатная и с открытым исходным кодом, представляющая собой венец эволюции централизованных систем контроля версий. Однако, зачастую большая часть потенциала Subversion остается нераскрытой. На Subversion смотрят, как на «какой-то инструмент для программистов», и он используется только для хранения программного кода и исключительно для обеспечения конкурентной работы. При этом его невозможно использовать для эффективного и целостного ответа на вопросы — «Почему сделаны эти изменения?» или эффективно искать по репозитарию, даже без учета временного измерения, то есть поиска по ревизиям. Достаточно бедна веб-навигация по репозиторию — по структуре файлов и ревизиям, нет возможностей пассивного мониторинга — подписок на изменения (например, критически важных файлов). По сути, из-за всего этого репозиторий компании выпадает из корпоративной базы знаний, плюс, возможности Subversion не используются для «не программистов» (HR, маркетинг, и других инфраструктурных подразделений) — например, для хранения документов.
Мы предлагаем использовать свободные системы с открытым кодом — ViewVC и SVNSearcher — чтобы заполнить эти пробелы, и бесплатно превратить SVN-репозитарий в часть корпоративной базы знаний с эффективным поиском, веб-навигацией и RSS-подписками.

Видеодоклад — (как обычно, можно смотреть, можно скачать).

Есть и слайды — если вы хотите ознакомится быстрее, или даже пересказать доклад кому-то еще:

Ну а для любителей текста есть и статья «Одежка для Subversion - ViewVC и SVNSearcher (Dressing Subversion: ViewVC and SVN-Searcher)».

Репликация: База Знаний «Заказных Информ Систем» → «Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)»

«Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)

2010-01-21T16:09:18Z

StasFomin:

3 августа в нашей компании прошел ранее анонсированный мастер-класс «Управление производством на основании численных данных».

Возможно его название звучало несколько скучно, но на самом деле, тема основана на культовой бизнес-литературе — произведениях доктора Элии Голдратта, автора производственной Теории Ограничений, основной постулат которой заключался от отказе от бессмысленной и беспощадной борьбы за тотальную производительность, вместо чего он предлагал сконцентрироваться на определении узких мест в производстве и продаже, и борьбе с ними, не взирая на падение локальных показателей оптимальности. Забавный был и способ изложения этой теории — в виде серии бизнес-производственных-романов («Цель», «Цель-2», «Критическая цепь», и др.), где главный герой, стартуя из безнадежной ситуации (бизнес разоряется, увольняют из университета, жена ушла, денег нет, пиджак в пыли, под кроватью брюки…) сконцентрировавшись на ключевых проблемах, находил серию эффективных решений в духе теории ограничений, и выходил победителем из сложившихся ситуаций. В общем, несмотря на некоторую инфантильность сюжета и бизнес-ситуаций с точки зрения реальностей современного мира, мы обязательно рекомендуем всем прочитать эти книги (там только о решении проблем на производстве, но и о решении семейных проблем). А конкретно этот тренинг ведущий Сергей Мартыненко основал на книге «Синдром стога сена» (по ссылке перевод первой части), где на 40 страницах текста без малейшей романтики и лирики рассматривается в цифрах оптимизация некоторого модельного производства, и где «на пальцах» читателя убеждают, что для достижения максимальной прибыли нужно жертвовать локальными оптимумами, и принимать решения, часто интуитивно непонятные. Сергей также приводил пример, иллюстрирующий, что похожие сценарии, когда действия, вроде бы направленные на улучшение процесса, на самом деле приводят к возникновению «бутылочного горла», бывают не только в материальном производстве, но и в разработке софта.

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

Далее, был доклад Стаса Фомина: «Теория ограничений и Линейное Программирование», о возможности математического моделирования широкого класса производственных задач, в контексте и на материале того же «Стога сена». Математическое моделирование — это мощный и гуманный инструмент поиска «бутылочного горлышка» на математической модели производства, позволяющий прогнозировать изменения и дрейф ограничений, без необходимости натурных экспериментов на живых людях и работающем производстве, как происходило в романах Голдратта. А линейное программирование — простая и в то же время мощная модель, в которой каждый менеджер должен уметь формулировать подходящие задачи оптимизации. На этом докладе сначала было сделано введение в постановку задач линейного программирования на совершенно классическом игрушечном примере, а затем, за двадцать минут были вживую, с участием зрителей, сформулированы и решены все вариации задач из «Синдрома стога сена», причем оказалось, что бездушный компьютер, снабженный формулировкой задачи, нашел более оптимальное решение, чем сам Голдратт в этой книге (это было обнаружено совершенно случайно, при подготовке презентации за час до выступления). Таким образом, были подведены итоги:

Человек не рожден для вычислений.
Рассуждения в литературной форме из-за аберраций восприятия легко уводят от оптимума.
Поиск оптимума в виде рассуждений трудно верифицировать.
Если есть возможность — нужно составить математическую модель. Человеку ее легко верифицировать, а машине — легко решать.

Опубликован видео-скринкаст, рекомендуем его смотреть в полноэкранном режиме. Впрочем можно скачать HD-видео, оно очень компактное, 80Mb.

Для очень быстрого поверхностного ознакомления опубликованы слайды презентации (но лучше смотрите видео):

Репликация: База Знаний «Заказных Информ Систем» → ««Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)»

Теория и практика Agile (2009-03-05)

2010-01-21T16:08:15Z

StasFomin:

Итак, вчера, (5 марта 2009 года) вполне успешно прошел ранее анонсированный семинар «Теория и практика Agile».

Так как меня (Стас Фомин) упрекают в многословности отчетов, буду краток. Семинар прошел успешно, — именно семинар, скорее даже «круглый стол», а не «доклады/лекции», ибо практически каждый слайд подвергся живому обсуждению, скажем, что некоторые «зрители» говорили и держали фокус внимания больше докладчиков.

Темы дискуссий, правда часто уплывали далеко в сторону. Казалось бы, какое отношение имеет дискуссия «Вменяемые Аналитики должны получать больше $4000» к теме «Аналитик в Agile?». Некоторые участники даже озвучили вывод, что оба доклада не имеют отношение к Agile. Можно констатировать, что период романтической влюбленности в модные agile-buzz-words прошел, звучит жесткая критика, и возможно (?) маятник ожиданий прихода «серебряной пули» в методологиях разработки софта скоро качнется обратно к водопадным моделям.

В общем, рекомендуем посмотреть видео — ибо мероприятие никак не сводится к слайдам/статье/аудио, много User-generated контента.

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

Андрей Бибичев «Аналитик в Agile».

Слайды и статья (хотя слайды слегка дополнены для этого семинара).
скачать видео

Александр Байкин «Гибкое управление требованиями».

Теперь о минусах. Ну, как обычно, пришло только чуть больше половины зарегистрированных, причем не пришла ни одна из зарегистрировавшихся девушек. Выносим устное порицание отсутствующим (кроме девушек, их мы поздравляем с наступающим 8 марта)!

Далее, «живой формат» растянул дискуссию несколько дольше ожидаемого — мероприятие, начавшись в 19:00 закончилось почти в 23:00, и далеко не все участники смогли сохранить бодрость духа и внимание до конца.

Но мы сделали выводы! На будущее будем или урезать scope — одна тема на такой вечерний семинар, или вводить некоторую тайм-модерацию ( гонг? девушки с «тайм-плакатами»?).

дополнительные материалы.

Репликация: База Знаний «Заказных Информ Систем» → «Теория и практика Agile (2009-03-05)»

ВикиЗакладки/Справка

2010-01-21T07:47:29Z

66.249.71.54: WikiBookmarks: load help page

ВикиЗакладки (WikiBookmarks) — расширение MediaWiki, позволяющее управлять публичными списками закладок с помощью Wiki-статьи. Автор расширения — Виталий Филиппов. Расширение распространяется по лицензии GPL (3-ей или более поздней версии). А это ссылка на домашнюю страницу расширения.

На странице Special:Bookmarks Вы всегда можете (точнее, уже смогли :-)) найти свежую версию справочной информации по ВикиЗакладкам.

ВикиЗакладки используются в виде небольшого Javascript-букмарклета (что такое букмарклет?). Чтобы установить такой букмарклет себе в браузер, введите название страницы, на которой Вы хотели бы поддерживать список своих закладок, нажмите кнопку Вывести ссылку и перетащите появившуюся ссылку себе на панель инструментов браузера или добавьте её в закладки браузера.

Страница:

Текст кнопки:

Далее, находясь на любой странице, которую Вы хотели бы запомнить на странице ВикиЗакладок, просто нажмите на добавленную в браузер кнопку. ВикиЗакладки запоминают адрес текущей страницы, её заголовок и выделенный на странице текст, если таковой имеется.

Новые закладки добавляются в список в начале статьи, под несколькими уровнями заголовков. По умолчанию это заголовки == Год == и его дочерний === Месяц Год === ("%Y" "%B %Y"). Предполагается, что это используется для классификации закладок по датам. Если Вы хотите изменить количество и/или формат заголовков, нужно добавить в начало страницы закладок комментарий вида

<!--BookmarkHeadings:"%Y" "%Y-%m" "%Y-%m-%d"-->

Из этого комментария ВикиЗакладки вырезают все строки, заключённые в кавычки, и используют их в качестве заголовков последовательных уровней. Формат строк совпадает с форматом функции PHP strftime() (на самом-то деле это функция libc, но это не важно).

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

<!--BookmarkDate:"%d %H:%M:%S"-->

Строка, указанная в кавычках внутри комментария, и будет принята за формат даты-времени закладок.

Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02)

2010-01-20T19:16:13Z

StasFomin:

Agile «по-крупному» (встреча AgileRussia.ru 2009-04-21)

2010-01-20T18:39:11Z

StasFomin:

Во вторник, 21 апреля, прошла аннонсированная ранее встреча сообщества AgileRussia.ru, озаглавленная «Agile по-крупному!». Изначально тема заявлялась, как разбор сложностей Agile в крупных командах и проектах, обсуждение тонкостей масштабирования, ведь все, что выходит за максимальный размер стандартной Agile-команды в 9 человек, уже требует специальных подходов.

Но на месте, обсуждение велось вокруг двух следующих, «живых» бизнес-кейсов:

«Waterfall2Agile — Agile для Большой Waterfall компании: нужен? как и что внедрять?» — это пришли ребята из широкоизвестной компании «C», они детально описали свой цикл разработки и структуру проектного управления своего Большого Продукта (достаточно заметить, что цикл тестирования релиза занимал у них 18 месяцев), пояснили возникающие проблемы, и запросили у сообщества предложений по улучшению процесса — включая как Agile-практики, так и технические/инструментальные решения.
«AgilePostmortem» — это была посмертная ретроспектива распределенного Agile-проекта, интересного высокотехнологичного стартапа, к сожалению, «не дожившего до весны».

Что касается кейса «Waterfall2Agile», то ребята из компании «С» заслуживают серьезного уважения за смелость публичного обсуждения внутренних проблем разработки — далеко не всякая команда (вне зависимости от agile она или нет) решится на это. Мы публикуем две части видео «Waterfall2Agile-1» — это описание текущих процессов и постановка проблем, и «Waterfall2Agile-2» — это предложенные сообществом решения после 50-ти минутного обсуждения. Будет очень интересно, если внедрение Agile в компании «C» продолжится, и через некоторое время, на очередной встрече мы узнаем о прогрессе в этой области, о новых проблемах и нетривиальных решениях.

С другой стороны, кейс «AgilePostmortem» более соответствовал заявленной теме встречи — хотя команда там была не такая большая, как в случае компании «С», но она была и географически распределенной, и работала в очень быстром темпе, с использованием большинства современных agile-практик и инструментов эффективной разработки. Публикую «спойлер» — в целом, «вскрытие показало, что больной умер ~~от вскрытия~~ здоровым/от несчастного случая», ибо почти все было сделано правильно. Хотя с другой стороны, возможно, некоторые небольшие проблемы, которые были вскрыты обсуждением, тоже внесли свою лепту, ибо проекту совсем чуть-чуть не хватило, «чтобы допрыгнуть до другой крыши» — то есть выпустить бета-версию, ведь альфа-версия уже была и успешно демонстрировалась.

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

Kanban vs. Scrum (встреча AgileRussia.ru 2009-07-07)

2010-01-20T18:18:23Z

StasFomin:

7 июля в нашей компании прошло очередное собрание сообщества AgileRussia, посвященного занимательнейшей теме – сравнению методологий разработки Scrum и Kanban. И если Scrum уже начал терять ореол свежести и модности, уже накопились претензии не от тех, кто «Пастернака не читал, но осуждает», а от реально практикующих Scrum в течение пары лет, то Kanban – штука в софтверной индустрии новая, и при этом не выдуманная заумь от софтверных методологов (или даже целых Институтов Программирования), а реальная практика, пришедшая из японского автомобилестроения – индустрии, уважаемой большинством программистов, даже не ездящих на «японках».

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

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

Этим и объясняется успех Scrum-а для измученных ~~нарзаном~~ RUP-ом или MS Project-ом. Но с другой стороны, у многих, особенно у пришедших к Scrum-у от «методологии ~~Бей и беги~~ Code-and-Fix», возникает много претензий к Scrum-практикам – можно ли еще упростить? Можно ли выкинуть еще один (детский? туземный?) ритуал? …

Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP. Неудивительно, что зал нашей компании был полон ПиЭмами, интересующимися – решит ли Kanban их проблемы со Scrum? Можно отказаться от итераций, планирования и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, как часто бывает, «истина где-то посередине» – и оптимальным будет именно сочетание Scrum и Kanban?

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

Правда мы должны предупредить читателя, что перед тем как смотреть видео, лучше выполнить домашнее задание и прочитать-пролистать вводные материалы по Kanban (собственно это заранее и проделали все собравшиеся):

Ну, а если лень, то тогда наверное лучше начать со второй части видео, где все-таки рассказывается об основных принципах и происхождении Kanban и проводится соотнесение его практик с Scrum.

В целом, содержание видео следующее. Первая часть – вербализация проблем Scrum, которых собравшиеся надеялись решить через Kanban. Была исписана целая ~~стена плача~~ маркерная доска, где были и здравые надежды и претензии типа «...доктор, я смогу после операции играть на скрипке?...», а советы по лечению, под стать вопросам, отсылали даже, скажем, к сексуальным играм для взрослых.

Кратко ключевые слова из этих проблем, ставшие «меню» этой встречи:

«Support Team». Техподдержка, багфиксинг, доработки.
«Сильно распределенная разработка». Разработчики в разных местах, их трудно синхронизовать.
«Сверхкроссфункциональные микрокоманды». Пара парней на все руки (см. сериал «IT Crowd»).
«Безудержный заказчик или нестабильный backlog»/«Несинхронизованный deployment»/«Хаотически меняющиеся приоритеты». Постоянные внезапные форс-мажорные заказы «фич» вне бэклога в текущую итерацию.
«Мутные красные бумажки», «Стек-вместо-очереди», «Research-and-Development».
«Scrum-шизофрения: Два product-ownera на одну команду».
«Случай-в-Питере» — Разработка «Софт-плюс-Железо», сложность синхронизации разных команд с разными технологиями.
«Растянутый Workflow задачи» — долгая многоитерационная постановка, или тестирование на стороне заказчика.
«Технологическая цепочка».
«Существенно разномощные задачи» — «фрагментация корзины бэклога».
«Проектная аритмия» (сбивается ритм демо, планирований, ретроспектив) — разный ритм участников разработки (включая заказчика).
«Проблема счастливой семейной жизни» — waste времени на ретроспективы.
«Дефицит Product Ownerов» — они могут стать критическим ресурсом.
«Расслабляющая команда», «Деградация через самоорганизованное командой уменьшение Scope».
«Трудно форсировать Аврал».

Далее была вторая, лекционная часть-ликбез, про историю, происхождение и основные принципы Kanban. Если вы осилили предложенные ранее ссылки – вполне можно пропустить без особого ущерба.

Ну и далее два часа горячего обсуждения, когда проверяли, сможет ли Kanban вылечить диагнозы, записанные «Доктором Agile» на доске при, так сказать, коллективном дифференциальном диагнозе. Тоже местами было более чем живо, где например услышишь о уставе боя танковых колонн.

Были и здравые идеи о комбинации Scrum и Kanban — например, отсадить на Kanban техподдержку, включая системных администраторов.

Кстати, каждое видео можно скачать (в отличном качестве, с обработкой от видеошумов).

Ну и на память – та самая доска проблем Scrum, которых пытались лечить Kanbanом.

А для любителей подкастов, прилагаем отдельно и аудиозапись:

[на всё окно][свернуть]

Репликация: База Знаний «Заказных Информ Систем» → «Kanban vs. Scrum (встреча AgileRussia.ru 2009-07-07)»

Метрики в Agile (встреча AgileRussia.ru 2009-08-18)

2010-01-20T17:40:25Z

StasFomin:

Была выбрана очень жаркая тема — «Метрики в Agile». На первый, неискушенный взгляд, кажется, что метрики — численно измеряемые параметры проекта, необходимы для грамотного управления в софтверных проектах любого типа, от каскадных, до Agile.

Популярные метафоры, сравнивающие управление проектом с поражающими цель ракетами, подразумевают это прямым текстом — какая «регуляция» возможна без сигналов с датчиков?

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

Однако не все так просто, тривиальные метафоры, может быть и адекватные для простого промышленного производства, не всегда годятся для софтверной разработки. Да и в обычной жизни, много ли из читателей ведут метрики «семейного проекта», в виде, например, семейной бухгалтерии? Ведь вроде бы тут все абсолютно просто, понятно что мерить, понятны бонусы — да и вообще, речь идет о той самой насущной рубашке, которая ближе к телу. А уж когда речь идет о «обычной» бухгалтерии, где в отличие от семейной приходится соответствовать внешним правилам — ненависть может зашкаливать.

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

Например, за метрики ратовал Том Демарко, автор широко разошедшейся фразы «If you can’t measure it, you can’t manage it»^[1], а как выглядит «полное покрытиями метриками» на практике, можно посмотреть здесь, особенно рекомендуем посмотреть живой Project Dashboard.

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

Если метрики связаны с системой оплаты-мотивирования, то все участники будут склонны к поведению, оптимизирующему измеряемые показатели, даже в ущерб общему делу. С этой стороны баррикад можно сослаться на Джоэла Спольски (см. например, его эссе «Измерения продуктивности», «Консалтинг по оценке производительности», «Метод экономической мотивации»), и, как ни странно, опять на Тома ДеМарко, с его свежей статьей «Software Engineering is Dead?!».

Есть и «умеренные» статьи, показывающие, что «меры хороши в меру», что можно найти общий базис для измерения для каскадных и аджайл проектов — см., например, наш перевод «Project Metrics for Software Development».

Так что по обсуждаемым вопросам нет никакого консенсуса даже в индустрии, и разумеется, среди собравшихся полусотни человек, наблюдался полный спектр мнений, ведь все собравшиеся — успешные профессионалы, имеют в багаже набор практик и принципов управления проектами, уже «оплаченных кровью», а не студенты, которых можно убедить в чем угодно одной лекцией. По сути, было очень плотное обсуждение вопроса профессионалами, эквивалентное по объему полугодовалому флейму в IT-форуме. Часто высказывались весьма полярные мнения — вот пруф-картинка (анимированный гиф) с огорошенным участником, вырезанная из видео встречи.

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

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

[на всё окно][свернуть]

Далее три части видео встречи.

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

Да, в результате обсуждение затянулось до глубокой ночи, и решено было ограничить тему только командными метриками, а тему «бизнес-метрик в Agile» перенести на следующую встречу через две недели.

Для подкастеров или просто любителей прилагаем и аудиозапись:

↑ см. Tom DeMarco «Controlling Software Projects: Management, Measurement and Estimation», 1982

Бизнес-метрики в Agile (встреча AgileRussia.ru 2009-09-01)

2010-01-20T17:10:13Z

StasFomin:

1 сентября в нашей компании прошла вторая встреча сообщества AgileRussia.ru, с продолжением темы «Метрики в Agile» (рекомендуем обязательно ознакомиться, с опубликованным нами отчетом по первой встрече). В этот раз, мы решили затронуть бизнес-метрики — в отличие, от более-менее осязаемых командных метрик, штуку более туманную и мистическую, по крайней мере на взгляд собравшихся, в большинстве своем разработчиков, ПМов и тестировщиков, а не бизнесменов.

Вероятно, то, что бизнес-метрики «страшно далеки от народа», объясняется и некоторое плутание коллективного разума при обсуждении — чего и кого только не поминали — от Голдратта до «Теории Ежей». Кстати, по теме рекомендуем почитать наш перевод статьи AgileEVM:_Measuring_Cost_Efficiency_Across_the_Product_Lifecycle с известного Agile-портала InfoQ.

В этот раз мы решили попробовать новый формат — вместо «говорящих голов вокруг флипчарта» был организован групповой майдмаппинг — коллективное обсуждение с фиксацией результатов на «ментальной карте».

Если вы не в курсе, что такое майндмапы («карты памяти», «карты интеллекта», «ментальные карты» — рекомендуем посмотреть наш небольшой доклад по теме майндмапов.

Таким образом, была проведена классификация проблем бизнеса, и этим проблемам были сопоставлены полезные для их решения метрики.

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

[на всё окно][свернуть]

Видео загружено в высоком разрешении, просьба смотреть его максимизированным (ну, или скачать).

Для желающих — есть аудиозапись встречи:

Репликация: База Знаний «Заказных Информ Систем» → «Бизнес-метрики в Agile (встреча AgileRussia.ru 2009-09-01)»

SECR-2008 (Отчет Стаса Фомина)

2010-01-19T15:46:16Z

BenderBot: 1 версия

GDD2009 (Отчет Клинчаева Олега)

2010-01-15T15:06:01Z

BenderBot: 1 версия

CustisWiki - Новые страницы [ru]

Право на справедливые расчеты

В основе заказной разработки ПО лежат специальные технологии

К теме информатизации единых расчетно-кассовых центров проявляют интерес не только представители власти, но и бизнес

Хотя бы на полшага быть впереди своих конкурентов

Knowledge Management: От Склада к Потоку (Software People-2010)

Hg-rebase-better-than-bzr-ithelps.sh

Bzr-rebase-dont-help.sh

Решение CUSTIS: информационная система для торговых компаний с уникальными бизнес-процессами

Внедрение модуля «Розничный магазин» CustIS в торговой сети «Спортмастер»

Важное преимущество заказной разработки – способность развиваться в разнородной информационной среде

Testopia

Свободные системы, спасающие разработчиков (РИТ-2010)

Презентация-трансформер: S5 на MediaWiki

Содержание

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд ГУРУ

Слайд

Слайд

Слайд

Слайд

Слайд НО

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд

Слайд Шаблоны и стили

Слайд Вставка кода

Слайд Mindmaps

Слайд TeX

Слайд GnuPlot

Слайд Flash-видео

Слайд

Слайд Всё-всё-всё

Слайд

Слайд

Слайд Live Preview

Слайд

Слайд

Google Notebook на MediaWiki

S5 (MediaWiki)

Расчетно-кассовые центры: проблемы и перспективы коммунального биллинга

О быте, политике и ИТ

ЕИРЦ и биллинг полного цикла

Архитектор в Agile (встреча AgileRussia.ru 2010-03-24)

Переход без остановки (Невозможное возможно)

ListFeed (расширение MediaWiki)

Как выжить городскому расчетному центру

Лучше один раз увидеть

Test1

AskTom in Moscow: отчет Дмитрия Подушко

AskTom in Moscow: отчет Дмитрия Белобородова

AskTom in Moscow: отчет Алексея Яблонского

Тренинг Андрея Бибичева по «DDD» (2010-03-03)

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

Аналитика московского образования

Путь к результативной автоматизации

Невыносимая тяжесть монолитной КИС

ЗИС: Последние новости

SEG-2010 (отчет Стаса Фомина)

MediaWiki — Серебряная пуля или швейцарский нож?

Управляемая ликвидация

Результативность автоматизации

Проводники в джунглях системной сложности. Автоматизация ключевых бизнес-процессов крупных предприятий

Восходящая «Звезда» MDM

Управление тестами с Testopia — недостающее звено? (SECR-2009)

Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)