Жизненный цикл (далее – ЖЦ) программного обеспечения (далее – ПО) состоит из ряда этапов, начинающихся стадией зарождения и заканчивающихся прекращением применения (рис. 1). Любая информационная система (далее – ИС) представляется совокупностью программных продуктов или ПО, тем самым определение жизненного цикла ПО и ИС тождественны. Вследствие того, что современные корпоративные информационные системы (далее – КИС) состоят из множества ИС, последнее применимо также и к КИС.
«До того, как я поделился с тобой своей проблемой, я даже не представлял, как это сделать» — примерно такие слова в итоге я слышу от каждого своего клиента. И вот почему.
Я не делаю супер‑уникальные, мега‑дорогие, адски сложные проекты. Не собираю команду из 30+ человек.
Я решаю ребусы, с которыми ко мне приходят предприниматели со стороны ИТ технологий: как оптимизировать, как выжать больше из того что уже работает, соединить несоединяемое, впихнуть невпихуемое.
Разберем несколько примеров.
Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения.
Внедрение практически любой ERP-системы требует как ее донастройки, так и доработки. Важное место в ходе имплементации имеют именно программные доработки, занимающие львиную долю проекта по сравнению с активностями кастомизации. От того, как правильно вы подойдете к вопросу планирования и реализации доработок, зависит успех ERP-проекта. Согласно статистике проектов внедрения, более 40% бизнес-потребностей пользователей требуют программной доработки, следовательно качественное планирование работ на проекте немыслимо без унифицированного подхода к оценке плановых трудозатрат на реализацию [1]. В связи с этим, в этой статье хотелось бы затронуть вопрос плановой оценки трудозатрат доработок и донастроек корпоративной информационной системы.
Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.
Существующая геополитическая ситуация обнажила множество проблем, в том числе зависимость отечественных предприятий от рынка зарубежного программного обеспечения. Курс на импортозамещение программных приложений был озвучен еще в 2014 году, однако лишь немногие компании действительно ему следовали, в частности, говоря о замещении программных решений класса ERP и ERP2. Да и чем руководствовались даже те немногие, кто решили заместить ERP системы на российские аналоги, тоже большой вопрос: стратегия импортозамещения или сокращение затрат, ведь общеизвестно, что траты на лицензии и поддержку зарубежных продуктов ежегодно обходятся в кругленькую сумму. Дошло даже до того, стоимость лицензии на определенные западные продукты оценивалась и контрактовалась как фиксированный процент от выручки предприятия. На текущий момент ситуация меняется в сторону реального, а не маркетингового импортозамещения. Фокус внимания с некогда популярного в Росси немецкого продукта SAP ERP закономерно смещается на линейку решений от 1С. Несомненно, есть еще и продукты от Галактики, Паруса, Монолита, однако по масштабу имплементаций в России 1С является лидером, который, кстати говоря, еще до этого конкурировал с SAP, Oracle и Microsoft. На страницах этой статьи, мы поговорим об отличие во внедрении двух ERP-продуктов: 1С и SAP.
Слухи о необходимости замены импортных программных продуктов ходят еще с 2014 года. Но до 2022 года, кажется, многие организации и их ИТ-директоры воспринимали это скорее, как маркетинговый трюк, а не реальную потребность. Уход большинства зарубежных вендоров из России вызвал панику среди руководства ИТ-индустрии. Что позже превратилось в целый ряд различных проектов: срочные переходы с глобального шаблона SAP на локальную версию, внедрение продуктов 1С, создание кастомных разработок для заполнения возникших пробелов на рынке, а также долгосрочные инициативы по импортозамещению. Все это затронуло многих в нашей области: занимаясь только проектами и продуктами SAP, мы пропустили множество других программных решений и способов их внедрения, которые демонстрируют разнообразие в мире информационных технологий и корпоративных информационных систем (КИС).
Наряду с каскадной методологией, являющейся основой имплементации большинства проектов SAP и гибридных SAP-методов, живущих фактически лишь на бумаге, специалистам доступны принципы Agile, применимые в кастомных разработках, спиралевидные модели внедрения, рекомендуемые 1С в технологии ТКВ (технология корпоративного внедрения) и много всего другого, на что мы не обращали должного внимания при господстве западных программных продуктов.
Поучаствовав в нескольких проектах внедрения 1С решений, а также кастомных разработок и имея более чем 15-ти летний опыт вовлечения в SAP проекты, я бы хотел поделиться результатами сравнения особенностей их реализации. Дальнейший материал будет рассматриваться в контексте следующих проектов: тиражирование SAP ERP, автоматизация закупочной деятельности на базе SAP ERP MM/IM/FM, имплементация 1С ERP, БП и ЗУП, подготовка целевой ИТ-архитектуры на базе 1С ERP, а также реализация кастомного SRM-решения, для которых было критически важно подобрать релевантную модель внедрения и доставить результат точно в срок.
Сопоставление организации планирования в машиностроении с подходами при планировании разработки программного обеспечения.
Продолжаем рассмотрение опыта автоматизации планирования и учета в машиностроении и сопоставляем с подходами в ИТ. С предыдущими частями статьи можете ознакомиться по ссылкам: Часть 1 и Часть 2.
10 лет, как мы с Дарьей Тишиной фанатично помогаем людям получать реабилитационные услуги, которые они по разным причинам не могут получить.
Это событие напомнило мне мероприятия моих родителей — «10 лет Реанимации», «10 лет Хирургии».
Привет, Хабр! Меня зовут Василь Хамидуллин, я работаю в ЦК тестирования АСУ ФХД в компании РСХБ‑Интех. Продолжу тему использования SAP для автоматизации подготовки данных. В прошлом материале говорили про LSMW и как данный инструмент можно использовать для автоматизации подготовки тестовых данных. Сегодня расскажу про способ загрузки исторических данных в SAP на основе SAP GUI Scripting.
Предлагаю продолжить анализ применимости подходов в машиностроении к ИТ. С первой частью можно ознакомиться по ссылке.
В первой части я сравнивал схему производственного цикла в машиностроении и цикл разработки программного обеспечения. На мой взгляд, процессы с точки зрения “управления” имеют очень много общего. Делюсь опытом планирования, который мне удалось подсмотреть, работая на “остатках” Информационно Вычислительного Центра (ИВЦ). На старте моей карьеры в ИТ численность персонала ИВЦ уже была гораздо меньше, чем в лучшие годы, и при этом постоянно сокращалась. Отчасти это можно объяснить тем, что ЕС-ЭВМ на тот момент серьезно устарели. При этом со временем ко мне пришло осознание того, что вся теория, которая была проработана еще во времена СССР, актуальна до сих пор, ведь основные принципы не изменились. Изменился только инструментарий.
Приветствую всех читателей Хабра!
Меня зовут Константин, занимаюсь разработкой ПО, в компании «Автомакон». На данный момент работаю на проекте для «ВкусВилл».
Занимаясь разработкой программного обеспечения, очень часто сталкиваюсь с вопросами, связанными с организацией планирования. Основной мой опыт работы связан с автоматизацией на машиностроительных предприятиях, что в свою очередь накладывает определенный отпечаток на мой подход к работе.
Свой первый опыт работы в IT я получил на одном из «заводов гигантов» родом из СССР (в момент распада последнего). Мне повезло, что тогда еще работали специалисты, которые организовывали автоматизацию планирования на заводе (но об этом чуть ниже). Что в дальнейшем успешно применялось на целом ряде заводов поменьше.
В данной статье сопоставляем опыт планирования в машиностроении с организацией разработки программного обеспечения.
Недавно решая проблему заказчика – крупного ритейлера, мы значительно ускорили работу одного из процессов, реализованных в SAP ERP. Периодически задания по загрузке цен работали ооооооооооооооооооооооооооочень медленно, причем задержка составляла не каких-нибудь 10 минут, а могла доходить до нескольких часов.
Для сравнения приводим два скрина. На первом отображено нормальное время выполнения задачи:
Всем привет!
Продолжаю публиковать странные и непонятные статьи.
Но вдруг, кому-то пригодится.
Поехали...
Хочется поговорить о времени, как о состоянии системы.
Но для начала нужна вводная: первая из них — временнАя переменная. С чего стартуем? Стартуем с дебага, как и я когда-то. Сидишь, трейсишь программу, и в дебаге у тебя есть несколько инструментов для похода по исходному коду: какой-нибудь step over, step into, run to cursor, step next. Ну, вроде все есть, но как бы: а где step back? Вы никогда не пролетали в отладке мимо того, что отлаживаете? И сколько раз приходилось перезапускать отладку? Может, я один такой… несчастливый?
Как раз, проблема в том, что обратные операции неочевидны. Процессоры, (может я и неправ, это просто гипотеза), не могут работать в обратном направлении по исходному коду. Операция степени в обратном направлении - это извлечение корня, например. Возможно, поэтому у нас нет такого очевидного и удобного, лично для меня, инструмента - как вернуться на строку назад от текущей…
Что может помочь? Например, какие-нибудь инструменты логирования. Мы берем область памяти, которая выделена для хранения значения переменной, и записываем в “блокнот”, что там происходит. В этом такте одно значение, в следующем другое… Мы формируем логи, так сказать.
Когда мы объявляем переменную, она будет “работать” с момента объявления до момента окончания работы исходного кода (выхода из подпрограммы или удаления этой переменной). Ее значение в процессе может быть многократно изменено без возможности восстановления. Обычно нас это устраивает, и значения в дебаге нас интересуют только в текущий момент. Обычно это говорит о том, что значение “вечно”, оно было таким всегда, даже если один такт назад это было не так.
Всем привет! Меня зовут Максим, я старший аналитик компании ITFB Group. В этом посте я хотел бы поговорить о BPMN и о бизнес-анализе в общем. Под понятием бизнес-анализа, говоря простым языком, можно понимать формализацию какой-либо деятельности или процессов. В наши дни понятие считается довольно устоявшимся, применяемым, пожалуй, во всех отраслях и сферах деятельности. Тем не менее принципы и правила бизнес-анализа максимально динамичны.
В этом посте речь пойдет о BPMN. Поделюсь своим опытом использования его как инструмента для упрощения работы бизнес-аналитика. Но в начале вас ждет небольшой исторический экскурс, за который заранее прошу простить.
В этой статье я решил поразмышлять, какие процессы в недвижимости можно оцифровать, какие преимущества и выгоды это дает бизнесу и где тут скрываются узкие места.
Привет, Хабр! Меня зовут Василь Хамидуллин, я работаю в ЦК тестирования АСУ ФХД в компании РСХБ-Интех. В прошлый раз я делился опытом тестирования бизнес процессов, внедряемых модулей SAP, в банке. Сегодня расскажу вам про LSMW, и как данный инструмент можно использовать для автоматизации подготовки тестовых данных.
В статье предлагается решение по быстрому написанию консистентного обновления базы данных в среде SAP NetWeaver на языке программирования ABAP (хотя подход может быть применен и к другим языкам). Описанный в статье подход является результатом субъективного опыта автора, но выполнен в соответствии с рекомендованным подходом ABAP-справки.
Судя по вакансиям на hh.ru, у некоторых компаний в русскоязычном сегменте наступила стадия принятия необходимости введения должности «Эксперт НСИ», хотя бы в виде функциональной роли.
Аббревиатурой «НСИ» (нормативно‑справочная информация) в компаниях может обозначаться достаточно широкий спектр источников информации, как структурированной (например таблицы единиц измерения или кодов операций в учётных системах и другие нетранзакционные данные), так и неструктурированной (тексты государственных или отраслевых стандартов, корпоративных организационно‑распорядительных документов и т. д.).
Нормализация и классификация записей справочников НСИ, в том числе справочника Номенклатур — одна из типовых функциональных обязанностей, входящих в описание роли «Эксперт НСИ».
Технически справочник НСИ в учётных системах может представляться в виде набора связанных таблиц в базе данных учётной системы, за содержание которых должен бы назначаться ответственный от бизнеса или группа таковых.
В прошлый раз мы рассказали о том, зачем «Северстали» понадобилась информационная система управления проектами и из чего она состоит. Сегодня продолжим и расскажем о том, как мы управляли проектом внедрения ИСУП и какие уроки для себя вынесли в процессе. На связи снова Павел Архиреев, старший менеджер нашего 1С-центра.
Привет! Меня зовут Николай, я разработчик 1С в компании SimbirSoft.
Зачастую при тестировании или анализе данных возникает необходимость сформировать стандартные бухгалтерские отчеты с определенным набором значений, а иногда в отборе требуется сравнить значение реквизита с множеством вариантов. К сожалению, в форме отбора не предусмотрены средства по загрузке значений из внешнего источника. Когда мне потребовалось проанализировать отчет с отбором более 10 000 позиций номенклатуры, я задумался о том, как автоматизировать процесс заполнения отбора. Оказалось, что реализовать это не так сложно. В своей статье я продемонстрирую способ решения этой задачи.
Кому будет полезно?
1С-разработчикам и другим 1С-специалистам, сталкивающимся с необходимостью импорта тысяч и десятков тысяч значений вручную.
Например, на создание 100 значений может уйти полчаса, но если требуется загрузить более 10 000, то это может занять дольше времени, и есть риск допустить ошибку, поскольку человеческий фактор никто не отменял.
Если автоматизировать импорт значений, тогда бухгалтеры или другие менеджеры смогут самостоятельно производить загрузку новых значений без привлечения разработчика.
