Редакция CNews готова принять пресс-релизы компаний на адрес news@cnews.ru.
Приглашаем вас делиться комментариями о материалах CNews на наших страницах платформ Facebook, Telegram и Twitter.
Число различных трехбуквенных аббревиатур, обозначающих новые классы информационных систем, на глазах - ERP, CRM, SCM, WMS, BPM, ESB, BPA, PLM, MDM, SRM и пр. Одновременно с этим в каждом классе увеличивается количество решений, предлагаемых на российском рынке. Как не ошибиться в таком многообразии предложений и сделать правильный выбор?
», организованной CNews Conferences и CNews Analytics 26 февраля 2015 г.
». Мероприятие состоялось 18 февраля 2016 г.
Число различных трехбуквенных аббревиатур, обозначающих новые классы информационных систем, на глазах - ERP, CRM, SCM, WMS, BPM, ESB, BPA, PLM, MDM, SRM и пр. Одновременно с этим в каждом классе увеличивается количество решений, предлагаемых на российском рынке. Как не ошибиться в таком многообразии предложений и сделать правильный выбор?
Наиболее простым способом наведения порядка в процессе выбора является четкая фиксация запросов в самом начале и последующий анализ их соответствия возможностям предлагаемых информационных систем. Это не занимает много времени, однако позволяет не только понять требования к выбираемой системе, но и обеспечить прозрачность принятия решения при выборе того или иного поставщика.
Одной из сфер, где активно применяются системы класса Business Process Management Suite (BPMs), является банковская отрасль. Именно при автоматизации бизнес-процессов банка проявляется сильная сторона систем BPMs – быстрота внесения изменений в автоматизированные процессы.
Процессный подход к управлению, о котором так много сказано и написано, часто требует серьезных изменений в компании, перераспределяющих полномочия существующих менеджеров. Существуют несколько вариантов, как выполнить эти изменения постепенно и наиболее безболезненно.
Термин "архитектура предприятия" (Enterprise Architecture) все чаще обсуждается на уровне ИТ-директоров, и сейчас даже бизнес стал его использовать. Сегодня мы продолжим <a href="http://www.cnews.ru/reviews/index.shtml?2012/06/21/493807" target="_blank">начатый ранее разговор</a> на эту тему. При анализе существующих подходов и стандартов по описанию архитектуры предприятия (Enterprise Architecture) можно столкнуться с большим числом артефактов – предметных областей описания, – которые нужно создать в проекте. Российская практика показывает, что на первых шагах можно обойтись и небольшим числом артефактов.
К автору - разумеется нельзя объять необъятное, и у архитекторов в полном соответствии с учениями дарвинизма совершенствуются часто используемые навыки и становится атавизмами неприменяемые. А это уже определяется сферой автоматизации. Скажем в 1С свыше 170-ти отраслевых конфигураций - и большая часть различий сделана на прикладном уровне. Есть ли смысл все объединять и тащить в ядро ? Получим систему с 10 тыс. крыжиков и сильной интерфенцией ошибок одного модуля на другой. Поэтому с ценности устойчивой работы - фиг с ним, пусть будет 170 вариантов дополнительных тегов-реквизитов клиента. Для фронт-офисных приложений часто вообще отходят от тяжелых архитектурных шаблонов типа ТЗ в упрощенные agile прототипы экранов, медиации, интеграции. Использование agile для бэк-офисных и инфраструктурных компонент приведет не только к росту сроков и бюджета, а скорее вообще сделает нереализуемым - тут ничего кроме waterfall технологии еще не придумано.... А раз так, то существенно расширяется круг проектируемых объектов - возможно даже проектирование существенно больше чем фаза разработки.
Но в целях системности - лучше сознательно объяснять упрощение того или иного архитектурного паттерна. Как в вопросе математику - "есть ли у слона крылья" ответ будет "есть ! но они равны нулю".
Автор пропустил минимум 2 принципиальных уровня, перескочив от Архитектуры деятельности сразу к Технический архитектуре. А между ними как минимум должна быть Функциональная архитектура, Системная архитектура. Еще явно выделяется Архитектура интеграции, Архитектура безопасности.
Андрей Константинович, было бы интересно получить ответы на вопросы, которые задавались в комментариях ... если у Вас будет возможность.А вообще тема достаточно интересная и ёмкая. И такой краткой статьи явно недостаточно, даже для описания конкретного практического опыта.
Отличная статья. Все верно и грамотно. Добавить бы примеры в кажду область предметную, скажем в БП, нотацию BPMN 2.0 и т.п. Ну добавить ни убавить, жаль большинству мимо ушей. Комментов нет, троллям неинтересно)
К этой статье очень подходит эпиграф из бессмертного стихотворения Михаила Лермонтова "Бородино":
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой...
Это все равно что замесить в одну "архитектуру" морфологическое представление и процессное представление о системе. Попробуйте с таким подходом создать архитектуру "человека". Франкенштейн гарантирован :)
1. Не очень понятно почему архитектура информации и данных (включая "расширение" - классификаторы документов) идут после архитектуры приложений. Если говорим что это модель as-is, тогда вполне такое может быть...
2. Не очень понятно что понимается под требованиями бизнеса к приложениям и какова гранулярность этих требований.
3. Описание функционала систем - на практике это кто-нибудь делал? Реально перелопатить неактуальные ТЗ написанные не по стандартам?
4. Не понятно почему используется термин "предметная область", а не классический "архитектурное представление" (architectical view.
5. Система проектов - видимо не очень удачное название, скорее это будет программа проектов. Да и следует ли считать программу проектов по переходу от as-is к to-be архитектурам элементом EA, а не элементом IT Governance (учитывая что собственно сама EA тоже равноправный элемент ITG, как и ИТ-стратегия). А вот программа проектов может быть вполне вложена в ИТ-стратегию - (зависит от задач, которые должна решать ИТ-стратегия).
Автор пропустил минимум 2 принципиальных уровня, перескочив от Архитектуры деятельности сразу к Технический архитектуре. А между ними как минимум должна быть Функциональная архитектура, Системная архитектура. Еще явно выделяется Архитектура интеграции, Архитектура безопасности.
Это очень похоже на фрагмент ИТ-стратегии. Некоторые вещи можно опустить для ясности. А некоторых не хватает. Например, нет целевой архитектуры приложений. а без нее ИТ-инфраструктуру строить опрометчиво.
Конфликтность функциональной структуры управления и отсутствие в ней механизмов ориентации на потребности клиента привели к появлению процессного и проектного подходов к управлению. Руководители проектов отвечают за разовые активности – проекты, а владельцы бизнес-процессов отвечают за регулярную деятельность. Но это идеальная картина бизнеса, а на первом шаге, когда еще не назначены владельцы бизнес-процессов в рамках всей компании, часто появляется отдельная должность – директор по бизнес-процессам - Chief Process Officer.
Спасибо за комментарий.
Именно для того, чтобы КРУПНЫЕ компании начали повышение операционной эффективности на базе процессного подхода и формируются процессные офисы и назначается директор по бизнес-процессам, которые отвечают за внедрение процессного подхода в компании.
Статья для меня была интересна.
Но хотелось бы понять мнение автора (и других коллег). А если "Процессный офис" создан и функциональные директора поддерживают введение сервисно-процессного подхода, то есть ли смысл в создании Комитета?
И, в чем бОльшая целесообразность такого Комитета по сравнению с периодическими совещаниями у Генерального директора?
Да и кстати, хочу добавить как практик в том числе. Если Вы хотите никогда не внедрить процессный подход или внедрить лишь его видимость - то установите систему BPMS))). Все системы BPMS имеют огромный недостаток, который я проиллюстрирую так - давайте внедрим в дрель мобильник. Как вам такой вариант?
Вопрос - вы же не можете, как в случае с компьютерными программами, сначала разработать, а потом кликнуть и запустить на выполнение. И соответственно каким образом внедренные процессы будут взаимодействовать со старой структурой еще не перераспределенной по процессам при том, что парадигмы кардинально разные работы? Мы решили этот вопрос создав параллельную с нуля, минимизируя контакты со старой моделью (юрлицом)
Спасибо за комментарий.
Именно для того, чтобы КРУПНЫЕ компании начали повышение операционной эффективности на базе процессного подхода и формируются процессные офисы и назначается директор по бизнес-процессам, которые отвечают за внедрение процессного подхода в компании.
Редакция CNews готова принять пресс-релизы компаний на адрес news@cnews.ru.
Приглашаем вас делиться комментариями о материалах CNews на наших страницах платформ Facebook, Telegram и Twitter.
