Привет, Хабр! Насвязи Антон Бобров — Product Owner HRM‑платформы K‑Team от ГК «КОРУС Консалтинг». Сегодня расскажу, как я вместе с командой проходил непростой путь от интегратора к продуктовому формату. Осторожно, в тексте много говорю про факапы, сложности и не даю обещаний, что будет легко.

Когда‑то мы были классическим интегратором, который адаптировал решения вендоров под нужды клиентов. Но со временем стало ясно: заказная разработка — это дорого, долго и не всегда эффективно. Мы рискнули и сделали шаг, который изменил все, — создали собственный продукт K‑Team HRM. Спойлер — это было не просто смело! А очень смело…

Как все начиналось или почему ИТ‑консалтинг — это еще не все

Внимание, а сейчас будет Product Placement!

Сегодня K‑Team HRM — это целая экосистема, которой пользуются более 100 000 сотрудников самых разных компаний. Среди наших клиентов крупные банки и промышленные корпорации, FMCG‑бренды, предприятия энергетической и нефтеперерабатывающей отрасли. Но к такому результату мы пришли не сразу.

Более десяти лет назад в КОРУСе появился департамент портальных решений. Сначала мы строили корпоративные порталы на MS SharePoint, затем расширили практику за счет «1С‑Битрикс», который предлагал более доступные лицензии и быстрый старт за счет готовых коробочных решений.

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

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

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

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

На что обращать внимание, когда принимаешь проект в середине реализации

Привет, меня зовут Ярослав, я Backend‑разработчик в отделе Битрикс24 CRM Корус консалтинг. Не так давно я впервые занимался настройкой CI/CD для Битрикс‑проектов, поэтому сегодня хочу поделиться шагами, которые помогут запустить свой первый пайплайн. Статья подойдёт для полных новичков в теме поставки кода.

Автор текста: Денис Салтыков
^{Руководитель практики повышения операционной эффективности, бизнес-архитектор «КОРУС Консалтинг»}

Занимаясь поиском вариантов оптимизации товарных запасов у наших клиентов, мы часто наблюдаем очень похожую картину. Заказчик использует категорийный подход — одинаковые принципы пополнения запасов для всех SKU внутри товарной категории. Чаще всего это очень простые бизнес‑правила, например: «По категории „X“ мы поддерживаем запас на 30 дней, а по категории „Y“ на 60 дней».

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

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

Меня зовут Татьяна Веселова, я руководитель направления ELMA в департаменте CRM и BPM КОРУСа. Недавно мы с коллегами обсуждали тему астрологии, и я решила пофантазировать на тему того, что будет, если совместить ИТ и астрологию.

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

Привет! Меня зовут Анастасия Криулина, я фасилитатор и ведущая командных сессий в КОРУСе. Сегодня хочу раскрыть тему ретроспективы проекта с новой стороны и поделиться не всегда очевидными ценностями, которые дает ретро всем участникам процесса: от руководителя проекта до продавцов и компании целиком.
Сразу сделаю ремарку: статья строится вокруг опыта ретроспектив в проектных компаниях, чья специфика отличается от продуктовых.  

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

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

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

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

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

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

Привет, Хабр! Меня зовут Артем Майоров, я администратор баз данных в компании MONS (КОРУС Консалтинг).
Расскажу, как мы не дали упасть больше 100 ПВЗ России благодаря спасению Percona
MySQL-сервера.
Подробнее, как это сделать и почему вообще его пришлось спасать, я рассказал в тексте!

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

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

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

Хорошо это или плохо – начинать работу с уже заданного конечного результата? Попробуем разобраться.

Всем привет! Меня зовут Алина Ужве, я руководитель проектов в департаменте корпоративных сервисов КОРУС Консалтинг. Как РП я очень часто взаимодействую со специалистами разных направлений, специализаций и даже возрастов.
Теория, описанная в данной статье представлена так, как я ее понимаю. Текст лишь частично раскрывает тему теории поколений, в конце статьи поделюсь интересными источниками, для самостоятельного изучения материала. Кто знает, вдруг вы найдете полезные инструменты, которые захотите использовать в своей работе?

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

В этой статье мы на основе своего опыта реализации проектов расскажем о вариантах и шагах для достижения цели на примере внедрения решений на платформе ELMA365.

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

Около 10 лет назад у меня возникла идея написать игру именно на Java, поскольку я использую этот язык в работе. Это был своего рода челлендж. Хотел попробовать себя, посмотреть, возможно ли это. И спойлер – возможно. Но проект дал мне больше, чем я мог рассчитывать.

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

Здоровые люди редко думают о своем здоровье, до тех пор пока не заболеют. Так и с конфликтами: пока не начнется открытая конфронтация, мало кто будет разрешать противоречия или стремиться завершить конфликт конструктивно. 

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

Привет! Меня зовут Антон Бурмаков, я QA Lead в КОРУСе. Со мной Герман Вавилин ( @Decayron85) из команды DevOps. Сегодня расскажем, как мы запараллелили смоук-тесты после мердж-реквестов, встроив их CI/CD и избавились от необходимости поддерживать множество окружений. 

Что в материале: 

Хабр, привет. На связи Оксана Рубанова, разработчик на платформе Optimacros.

Бывают моменты, когда от тебя ничего не зависит, случается что-то плохое просто потому, что оно иногда случается. А бывают моменты, когда понимаешь, что ты – часть / причина этого плохого, но не понимаешь, как до этого докатился, с чего все началось и главное, как теперь это исправить, учитывая масштаб бедствия (и не важно, личная это сфера или рабочая).

Так что ту часть проблем, на которую я имею влияние, я захотела проанализировать и улучшить.

В статье поговорим про:

1. Теории накопительного эффекта и разрушенных окон и их влияния на нас

2. Проблему внутреннего тестирование на проектах и идею, как его можно усилить

3. Рабочий эксперимент с командой, длинною в месяц

4. Результаты участников по итогам челленджа

5. Мои выводы со стороны организатора