Cases
Engagements from my practice, grouped around the kinds of decisions they involved — not the tools or frameworks used. Each card opens to a structured view: context, the decision challenge, constraints and trade-offs, the architectural or strategic perspective applied, and the outcome.
Most cases fall into one of two patterns:
- BUILD — launching a new business unit, product, or platform from zero, and designing the structure that lets it scale.
- FIX — restoring order after M&A, reorganization, or accumulated complexity: cost, risk, legacy exposure, or operational drag.
In practice, most engagements sit on the boundary between the two.
Use the filters below to narrow by industry, role, or functional domain.
Highlights
A few engagements that illustrate the type of outcomes this work tends to produce:
- National top-2 aviation hub. Product portfolio reduced from 4,600 to 1,200 items and time-to-market cut threefold — by rebuilding classification, lifecycle rules, and governance across 19 legal entities.
- Fuel retail with over 70,000 B2B counterparties. Reconciliation time cut 6× and fraud-related losses cut 10× — by replacing paper-coupon settlements with a cashless platform and architecting the surrounding governance.
- Global IT services firm, approximately 68,000 employees. 80% of HR inquiries across 12 processes resolved without human intervention, 99% answer accuracy, response times from days to minutes — by architecting the HR assistant and its knowledge and integration layer.
The full list, with filters by industry, role, and functional domain, is below.
HR self-service assistant to reduce response time and operational load
HR self-service assistant to reduce response time and operational load
Context
EPAM operated at a scale of 68,000 employees and faced high volume of routine HR inquiries across 12 processes. Human-operated response times often stretched into several days, reducing employee satisfaction and limiting HR capacity for higher-value work.
The Decision Challenge
The decision challenge was how to introduce an automated assistant that improves speed and consistency without creating new risk through incorrect guidance or poor escalation handling. A low-quality assistant would increase support load and erode trust; a conservative design would fail to reduce operational burden.
Constraints and Trade-offs
HR processes include policy nuance and exceptions, so automation had to be bounded by a clear escalation model. Higher automation rates require a disciplined knowledge base and feedback loop; faster rollout increases the risk of inconsistent answers. Scaling from an initial user base to the full organization required stability and predictable operations.
Architectural / Strategic Perspective
The work treated the assistant as part of the HR service operating model: knowledge-driven resolution for routine cases, controlled escalation to human experts, and measurable quality signals to guide continuous improvement. The focus was on decision safety and operational governance rather than on a “chatbot feature set.”
Outcome and Impact
The assistant served 35,000 employees and continued expanding toward full coverage. Response times dropped from days to minutes, 80% of inquiries were resolved without human intervention, and answer accuracy reached 99%, saving thousands of man-hours per year and reducing operational load on HR.
Lessons Learned
Service automation succeeds when the organization treats it as a governance problem—clear boundaries, measurable quality, and a reliable escalation path—rather than as a conversational interface.
Capability-based planning methodology and EA management product
Capability-based planning methodology and EA management product
Context
Transitrix identified market demand for more effective tools that support strategic planning through enterprise architecture concepts. Many organizations struggle to connect strategy to execution because capabilities, initiatives, and investments are not linked in a consistent way.
The Decision Challenge
The decision challenge was how to build a product that is methodologically credible (useful for real planning) without becoming an over-engineered framework that only experts can operate. A weak methodology would create artifacts with limited decision value; an overly complex one would limit adoption.
Constraints and Trade-offs
Enterprise architects expect rigor, but they also need practicality and ease of adoption. A product needed to support early adopters quickly while preserving a roadmap for deeper capability-based planning. Long product cycles required continual validation against real user workflows and competing tools.
Architectural / Strategic Perspective
The work emphasized a capability-based planning model: consistent capability definitions, relationships to initiatives and outcomes, and tooling that supports repeatable planning scenarios. Product evolution was guided by feedback loops with enterprise architects to ensure alignment between the methodology and day-to-day planning work.
Outcome and Impact
A capability-based planning methodology and corresponding tooling were established, with an MVP in use by early adopters and a multi-year roadmap guiding further evolution.
Lessons Learned
EA tooling delivers value when it helps leaders make fewer, better decisions—not when it produces more artifacts. Capability-based planning works when it becomes a shared language across strategy and delivery.
AI-agent proof-of-concept for product development process automation
AI-agent proof-of-concept for product development process automation
Context
A client’s product development process for launching and evolving confectionery products for the European market was lengthy and unpredictable. The process involved iterative workflows across multiple functions, making it difficult to forecast timelines and manage a product portfolio effectively.
The Decision Challenge
The decision challenge was whether AI agents could reduce cycle time and increase predictability without turning the process into a fragile automation layer. A poor POC would demonstrate “automation theater” rather than producing credible evidence that the approach can be governed and scaled.
Constraints and Trade-offs
Product development includes complex exceptions and human judgment, limiting how much can be automated safely. Increasing automation improves speed potential but raises risks around correctness, traceability, and stakeholder trust. A POC needed to focus on decision-relevant fragments and make outcomes measurable.
Architectural / Strategic Perspective
The work treated the process as a sequence of decision points and artifacts, identifying where agent-based support can reduce coordination cost and where human judgment must remain primary. The design emphasized traceability and analytics so the organization can observe process state and performance, not just “run bots.”
Outcome and Impact
A working proof-of-concept demonstrated the practicality of automating selected product development activities with AI agents. The client confirmed potential cycle time reduction (up to 5×) and moved into negotiations for a full-scale implementation.
Lessons Learned
Agent-based automation is compelling when it turns a complex process into an observable system—where work state, ownership, and decisions are trackable—rather than simply replacing people with scripts.
Remuneration process redesign with AI-automation readiness
Remuneration process redesign with AI-automation readiness
Context
A vertically integrated oil and gas company sought to overhaul remuneration planning and calculation for fixed and variable components. The existing cycle was long (around 11 weeks), error-prone, and exposed to human-factor risks, including weak transparency in bonus-related decisions.
The Decision Challenge
The decision challenge was to redesign the process so that it becomes both faster and more controlled, while preparing it for selective automation. Automating a flawed process would amplify problems; redesigning without an automation perspective would preserve long cycle time and manual burden.
Constraints and Trade-offs
Remuneration decisions are sensitive and politically charged, raising the cost of ambiguity and inconsistency. Achieving a projected reduction to 1–2 weeks required clear decision points, standardized inputs, and explicit rules. Increased control improves transparency but can be perceived as reduced flexibility by stakeholders.
Architectural / Strategic Perspective
The work structured the process around capabilities and decision points, then identified fragments suitable for AI-enabled assistance and automation. Agent requirements were defined in terms of roles, inputs/outputs, and interaction logic, with emphasis on explainability and governance rather than “black box” automation.
Outcome and Impact
An agreed target process description and AI agent requirements were prepared, positioning the organization to move toward an AI-automated process. The design established a credible path to reduce cycle time from 11 weeks to 1–2 weeks while strengthening transparency and reducing error and abuse risks.
Lessons Learned
Automation in sensitive processes works when it is a governance choice: the organization first agrees on decision rules and accountability, and only then uses AI to compress cycle time.
Stablecoin proof-of-concept framing under delivery constraints
Stablecoin proof-of-concept framing under delivery constraints
Context
A leading bank in Asia explored a national stablecoin concept and needed to validate feasibility through a proof of concept. The engagement required rapid clarity on what a POC can prove, and what it cannot, given surrounding regulatory and operational realities.
The Decision Challenge
The decision challenge was to define a POC scope that meaningfully reduces uncertainty: demonstrating a coherent operating model and the core system behaviors while avoiding premature commitment to a full-scale architecture. Over-scoping would delay learning; under-scoping would produce a demo with little decision value.
Constraints and Trade-offs
Time constraints demanded prioritization of the most decision-relevant capabilities. A private ledger approach introduces governance questions about issuance, circulation, and control. The solution concept needed to remain adaptable so future regulatory or business decisions can be incorporated without a full redesign.
Architectural / Strategic Perspective
The work focused on requirements and a solution concept that makes responsibilities explicit: how value is issued, how transactions are represented, what constraints matter, and what interfaces and controls are required. A roadmap clarified the sequence from POC learning to implementation decisions.
Outcome and Impact
A solution concept aligned to requirements and constraints, together with a roadmap for next steps, enabled the client to move from exploration to an implementation initiative.
Lessons Learned
Financial POCs create value when they turn “is it possible?” into “what decisions must be made next, and what risks do those decisions carry?”—not when they optimize a prototype.
Stabilizing fuel retail operations affected by loyalty outages
Stabilizing fuel retail operations affected by loyalty outages
Context
ADNOC experienced critical disruptions at petrol stations where loyalty program outages could cascade into full service shutdowns. The issue sat at the intersection of operational processes, integrations, and station hardware/software dependencies.
The Decision Challenge
The decision challenge was how to restore stability quickly while avoiding a “patch and hope” cycle that would repeat the same incidents. The wrong approach would either prolong revenue loss (if too slow) or create temporary fixes that fail under the next load or change.
Constraints and Trade-offs
Retail fuel operations tolerate little downtime, so remediation had to minimize operational risk. The landscape was complex, spanning loyalty, retail systems, finance, POS, and dispenser interactions. Short-term stabilization needed to coexist with a longer-term direction for resilience and simplification.
Architectural / Strategic Perspective
The analysis focused on identifying failure points and integration bottlenecks across the end-to-end station flow, then translating findings into actionable architectural recommendations. The intent was to make dependencies explicit so that “loyalty” stops being a single point of operational failure.
Outcome and Impact
Immediate disruptions were resolved and operational stability was restored. The organization received a forward plan for improving the IT landscape to prevent recurrence and support ongoing digital growth.
Lessons Learned
Operational incidents in retail are often architecture problems in disguise: resilience improves when critical flows have explicit dependency management and failure containment.
Product domain restructuring for a digital marketplace direction
Product domain restructuring for a digital marketplace direction
Context
BTC continued its transformation toward a digital services marketplace, but its product domain remained shaped around traditional telecom offerings. The catalog was cluttered, concepts of product and offer were mixed, partner onboarding was not supported, and both configuration and pricing were inflexible.
The Decision Challenge
The decision challenge was how to redesign the product domain so that it supports marketplace behaviors (partner products, bundling, flexible configuration and pricing) without destabilizing existing operations. A wrong direction would either preserve telecom-era constraints or introduce a complex model the organization could not operate.
Constraints and Trade-offs
The organization had low domain maturity, and immediate pain required pragmatic near-term improvements alongside a longer-term direction. Flexibility increases model complexity and governance requirements. Partner enablement introduces new responsibilities for onboarding, quality control, and lifecycle management.
Architectural / Strategic Perspective
The work structured the domain around clear concepts and responsibilities and compared solution options through a capability model. The emphasis was on how the organization would reason about products, offers, configurations, bundles, and pricing rules—so that both technology choices and operating processes align with marketplace strategy.
Outcome and Impact
A product domain concept and a change plan were established, and vendor selection activities for catalog and marketplace solutions were initiated. The organization gained a clearer, strategy-aligned direction for improving product manageability and enabling ecosystem growth.
Lessons Learned
Product domain transformations succeed when the organization stops treating the catalog as a list and starts treating it as a model of decisions—where governance and definitions matter as much as systems.
Subscription management blueprint for lead-to-cash transformation
Subscription management blueprint for lead-to-cash transformation
Context
Danfoss moved toward a service-based business model, which required subscription management as a connective layer between customer engagement and enterprise operations. The organization needed a coherent blueprint before committing to implementation.
The Decision Challenge
The decision challenge was how to design a subscription capability that supports the business shift without creating a brittle integration layer. A weak design would lock the organization into expensive workarounds between commercial processes and operational fulfillment.
Constraints and Trade-offs
Existing systems and processes set constraints on what could change first. A “perfect” target state would delay the transition; a minimal approach risked pushing complexity into manual processes. Vendor selection required a clear articulation of required capabilities and an understanding of where differentiation matters.
Architectural / Strategic Perspective
The work framed the subscription solution as a capability map and a blueprint of responsibilities and interfaces. The roadmap prioritized steps that unlock the transition: sequencing capabilities, clarifying ownership, and establishing a pragmatic integration approach between commercial and operational domains.
Outcome and Impact
A solution blueprint, capability map, and prioritized roadmap were established, providing a clear basis for selecting a provider and proceeding into development with aligned expectations.
Lessons Learned
Business model shifts are rarely blocked by technology alone; they are blocked by unclear responsibility boundaries. A good blueprint makes those boundaries explicit before the organization starts buying or building.
Authorization cockpit planning under MVP time pressure
Authorization cockpit planning under MVP time pressure
Context
Danfoss needed a new authorization management application for users and partners, with an MVP expected within the year. The initiative required clarity on scope, priorities, and how the solution fits the broader identity and access landscape.
The Decision Challenge
The decision challenge was to define an MVP that is meaningful and safe: enough capability to support partner authorization needs, but not so much that it becomes a multi-year program. Vendor choice also depended on an explicit view of required capabilities and the organization’s constraints.
Constraints and Trade-offs
Time-to-MVP limited how much could be built or standardized in the first iteration. Reuse of existing UI components reduced delivery risk but constrained design flexibility. Centralization improves governance, but it increases dependency on shared services and decision-making speed.
Architectural / Strategic Perspective
The work focused on capability-based reasoning: what authorization decisions must be supported, what context is required, and how policy governance should work over time. A prioritized backlog and roadmap were used to make trade-offs explicit for both vendor selection and internal planning.
Outcome and Impact
A capability map, prioritized scope, and implementation roadmap were established, supporting a cost-effective vendor selection and enabling the transition from uncertainty to a controlled build plan.
Lessons Learned
Identity initiatives fail when MVP scope is defined by features; they succeed when MVP is defined by the minimum decision set the organization must control safely.
Target-state information architecture for marketplace transformation
Target-state information architecture for marketplace transformation
Context
BTC aimed to evolve from a traditional telecom operator into a digital services marketplace, expanding into adjacent digital domains. Competitive pressure increased the cost of slow transformation, while the existing information landscape was not structured for a multi-domain marketplace model.
The Decision Challenge
The decision challenge was to define a target information architecture that is ambitious enough to support marketplace growth, yet grounded enough to be actionable. Over-engineering the target state would stall delivery; under-specifying it would lead to inconsistent implementations and escalating integration costs.
Constraints and Trade-offs
Transformation had to coexist with ongoing telecom operations. New digital services introduce new information entities and relationships, and the organization needed a common vocabulary to prevent each domain from inventing incompatible models. A roadmap had to balance sequencing and dependencies across domains rather than assuming a single “big transformation”.
Architectural / Strategic Perspective
The work structured the enterprise around key information entities and their interactions, then connected that model to capabilities and customer journeys. The aim was to provide an architecture that enables consistent decisions across domains: what data is authoritative where, how information flows, and what changes must happen first to unlock later steps.
Outcome and Impact
A target-state information architecture and transformation roadmap were established, giving BTC a clearer basis for system and data evolution toward a marketplace model and reducing the risk of fragmented domain-specific implementations.
Lessons Learned
Marketplace transformations succeed when information architecture is treated as a coordination mechanism across domains—so teams can move quickly without diverging on definitions.
Core retail platform roadmap under M&A-driven complexity
Core retail platform roadmap under M&A-driven complexity
Context
Ahold Delhaize underwent multiple transformations and acquisitions, creating a complex retail and IT landscape with duplicated functions and unclear platform ownership. Omnichannel growth depended on deciding what to standardize and what to allow to remain local.
The Decision Challenge
The decision challenge was how to define a core retail platform direction that optimizes investment without stalling delivery. Choosing “one platform for everything” can be unrealistic in post-merger environments; choosing to keep everything local preserves duplication and cost.
Constraints and Trade-offs
Different banners and regions often have legitimate differences, but duplicated capabilities create ongoing spend and inconsistent customer experience. A roadmap had to be credible: specific enough to drive choices, but flexible enough to account for organizational realities and sequencing constraints.
Architectural / Strategic Perspective
The work centered on discovery and capability-based reasoning: mapping application functions to business capabilities to identify overlaps, gaps, and opportunities for consolidation. The roadmap was structured to support incremental convergence—reducing duplication while maintaining delivery momentum.
Outcome and Impact
A strategic roadmap for the core retail platform was established, enabling more informed decisions about which systems to retain, rationalize, or replace. The client gained a clearer basis for avoiding functional duplication and optimizing investments.
Lessons Learned
In post-M&A landscapes, roadmaps matter because they make trade-offs explicit so stakeholders can align on what will converge, when, and why.
Profile storage and migration to operationalize unified profiles
Profile storage and migration to operationalize unified profiles
Context
After establishing a unified profile concept, EPAM needed a practical implementation: centralized profile storage that consolidates data from multiple sources and provides reliable access for consuming systems. Without a shared storage capability, the concept would remain theoretical and fragmentation would persist.
The Decision Challenge
The decision was how to implement profile storage in a way that remains stable while source systems evolve. A one-time migration would not survive dynamic changes in source formats and rules; a more robust approach required explicit operating rules and controlled transformations, increasing initial complexity.
Constraints and Trade-offs
Source systems were changing over time, and profile data required transformation and normalization. Strong consistency improves trust but can slow onboarding of new sources; faster onboarding increases the risk of inconsistent profile semantics. The solution needed to be attractive enough that consuming systems would adopt it rather than building their own copies.
Architectural / Strategic Perspective
The work treated profile storage as a governed data product: defined profile semantics, explicit ingestion and transformation rules, and predictable consumption patterns. Migration planning focused on integrity—verifiable mappings and controlled evolution—so the organization can keep a single profile contract even as sources change.
Outcome and Impact
A profile storage capability and migration approach were established, enabling consuming systems to integrate around a unified profile source. The organization gained a scalable base for further expansion of profile-driven processes and access control.
Lessons Learned
Unified profile initiatives fail when migration is treated as “moving data”; they succeed when profile semantics are treated as a living contract with controlled evolution.
Centralized permission model for mixed user populations
Centralized permission model for mixed user populations
Context
EPAM operated many internal and external systems used by employees and non-employees (students, subcontractors, partners). Access control was decentralized, handled separately by each system and process, increasing cost and the risk of inconsistent or excessive access.
The Decision Challenge
The decision was whether to keep permissions embedded in each system or move to a centralized model that enforces consistent rules across the landscape. Centralization can reduce risk and effort, but it concentrates responsibility and requires careful definition of roles, resources, and ownership.
Constraints and Trade-offs
The solution needed to support both role-based and resource-based access patterns, reflecting how real organizations operate. Increased flexibility improves fit but can create configuration complexity; simplicity improves operability but risks forcing exceptions back into application-specific logic.
Architectural / Strategic Perspective
The work focused on defining a permission contract that systems can rely on: clear identity inputs, consistent policy evaluation, and governance over rule changes. The aim was to reduce unauthorized access risk by making permission decisions explicit and centrally auditable.
Outcome and Impact
A concept for a centralized permission engine was established, enabling both role-based and resource-based assignment patterns. The organization gained a foundation for reducing access management labor and strengthening control over sensitive information and systems.
Lessons Learned
Access management improves when permissions are treated as a shared enterprise capability—with explicit governance—rather than as scattered implementations hidden inside applications.
Unified contact profile concept for enterprise-wide consistency
Unified contact profile concept for enterprise-wide consistency
Context
EPAM maintained multiple systems that stored information about employees and other contact types (students, interns, community members). Fragmentation created discrepancies, confusion in processes, and barriers to unification and consistent management.
The Decision Challenge
The decision was whether to keep “profiles” as system-specific representations or establish a shared enterprise concept that can be reused across processes and systems. A weak concept would add another layer of inconsistency; an overly rigid one would block real-world use cases and slow adoption.
Constraints and Trade-offs
Different contact types have different lifecycles and sensitivity levels, which complicates a single model. Unification improves consistency and reduces rework, but it requires explicit transformation rules and agreement on what is core versus what remains contextual. The concept also needed to be usable as a foundation for subsequent initiatives.
Architectural / Strategic Perspective
The work defined a shared information architecture for contact profiles and clarified process-level responsibilities for creating, updating, and consuming profiles. The emphasis was on explicit data flows and transformation rules so downstream systems can integrate without re-deriving identity and profile semantics.
Outcome and Impact
A unified profile concept was established and became the foundation for multiple follow-up initiatives (including centralized permission management and profile storage), reducing duplication and supporting more consistent processes and data management across the organization.
Lessons Learned
A “single profile” is only valuable when it is a contract: a shared definition that reduces argument and rework every time a new system or process needs identity data.
People profile management under global compliance and organizational change
People profile management under global compliance and organizational change
Context
EPAM experienced large-scale organizational change driven by remote work and relocations. People data existed across fragmented and outdated systems, and the scope extended beyond employees to external contacts, students, and community members. Operating across 58 countries also raised significant data privacy obligations.
The Decision Challenge
The decision was how to redesign people profile management so that it supports evolving organizational structures while remaining compliant and operable globally. A narrow HR-only approach would fail to address broader contact use cases; an overly broad approach risked unclear ownership and uncontrolled data growth.
Constraints and Trade-offs
Compliance requirements varied by country, and legacy data was inconsistent. Migration and transformation could not be treated as a one-time event because source systems and data formats continued to change. Strong governance improves privacy posture but can slow operational responsiveness if responsibilities and rules are not clearly defined.
Architectural / Strategic Perspective
The work focused on defining requirements and operating rules for a profile storage capability: what constitutes a profile, how profiles change over time, how transformations are governed, and how consuming systems should interact with a single source of truth. The emphasis was on traceability and defensible compliance rather than tool-specific solutions.
Outcome and Impact
A requirements and specification package for a new people profile management capability was established, supporting process efficiency improvements, reduction of accounting errors, and compliance alignment across countries. The work created a foundation for scalable evolution of the people data landscape.
Lessons Learned
Global people data management is a governance problem first: without explicit rules and ownership, “data privacy compliance” becomes an endless set of exceptions rather than a stable operating model.
Operating model reset for an IT subsidiary with modern delivery practices
Operating model reset for an IT subsidiary with modern delivery practices
Context
Domodedovo Integration (DI) faced low efficiency and an unattractive engineering environment, limiting talent attraction and reinforcing reliance on outdated technologies and ways of working. The department also needed to become viable for serving external clients, not only internal demand.
The Decision Challenge
The decision was how to modernize DI’s operating model without turning transformation into a disruption spiral. Changing methods and structures can create short-term productivity loss; avoiding change entrenches unprofitability and weak market credibility.
Constraints and Trade-offs
Transformation needed to address both organizational structure and delivery practices while maintaining the ability to support ongoing work. Faster adoption of modern practices increases learning pressure; slower adoption prolongs the talent and credibility problem. The changes also had to align with an enterprise-level IT strategy.
Architectural / Strategic Perspective
The approach emphasized capability mapping and a roadmap that links business needs to IT improvements. Methodological changes were treated as governance choices: how work is prioritized, how change is managed, and how delivery becomes predictable and transparent for both internal and external clients.
Outcome and Impact
DI gained the basis to work with external clients and adopted modern change and delivery practices, improving its ability to attract talent and build profitability over time. The organization also received a clearer, business-aligned IT direction for DI’s evolution.
Lessons Learned
Operational transformation works when practices are tied to measurable business outcomes—predictability, talent retention, and customer trust—rather than adopted as “modernity” for its own sake.
IT strategy aligned to airport business goals
IT strategy aligned to airport business goals
Context
Domodedovo Airport needed an IT strategy that supported business growth rather than a set of disconnected departmental plans. Without an integrated view, investment decisions drift toward local optimization and vendor-driven commitments.
The Decision Challenge
The decision challenge was how to translate enterprise goals into a coherent IT direction that could guide priorities, architecture choices, and vendor selection. The risk of getting it wrong was long-term: expensive technology commitments that do not compound into stronger capabilities.
Constraints and Trade-offs
Strategic work had to align multiple IT subfunctions while remaining understandable to business leadership. Vendor discussions added pressure to make decisions before all uncertainty could be resolved. A strategy needed enough specificity to drive action, but enough flexibility to adapt as business priorities shifted.
Architectural / Strategic Perspective
The work connected business capabilities to enabling technology direction, establishing an enterprise architecture view that made dependencies visible. Vendor and solution selection was treated as a strategic constraint: choices were evaluated by how they supported the target direction, not by feature lists alone.
Outcome and Impact
A cohesive IT strategy integrated with business goals was established, supported by an enterprise architecture view and selected solution directions. The airport gained a clearer basis for future transformations and investment prioritization.
Lessons Learned
IT strategy is most valuable when it narrows choice: it provides a principled way to say “no” to investments that do not strengthen the capabilities the business actually needs.
Product portfolio rationalization and development process reset
Product portfolio rationalization and development process reset
Context
Domodedovo Airport’s product portfolio had grown to 4,600 items without sufficient classification and governance, creating duplication, functional overlap, and outdated positions. The organization lacked a clear product strategy and a development process that could keep the portfolio efficient.
The Decision Challenge
The decision was how aggressively to reduce and restructure the portfolio without damaging profitability. Cutting too cautiously would preserve inefficiency; cutting too aggressively would remove value-bearing products and create internal resistance. A second challenge was whether to treat the issue as catalog cleanup or as a process and operating model redesign.
Constraints and Trade-offs
The portfolio spanned 19 legal entities, requiring a methodology that could be taught and applied consistently. Faster reduction favored rule-of-thumb decisions; sustainable improvement required classification, decision criteria, and a repeatable product development process. Change also needed to be acceptable to product owners and governance bodies.
Architectural / Strategic Perspective
The approach treated the portfolio as a managed system: classification, lifecycle rules, and decision criteria tied to profitability and operational impact. Process redesign targeted predictable time-to-market by clarifying stages, responsibilities, and the information required for product decisions.
Outcome and Impact
The portfolio was reduced from 4,600 to 1,200 products without compromising profitability. Time-to-market decreased threefold, and the profit-per-product indicator increased through removal of inefficient duplication and clearer portfolio governance.
Lessons Learned
Portfolio efficiency is not achieved by “cleaning a catalog”; it is achieved by making product decisions repeatable, with criteria that survive personnel change and organizational pressure.
Crisis pivot of an internal IT unit toward external clients
Crisis pivot of an internal IT unit toward external clients
Context
During the COVID-19 shock, the aviation industry faced severe demand pressure. Domodedovo Integration (DI) historically served the airport as an internal client, and its sustainability was threatened when the core business entered crisis mode.
The Decision Challenge
The central decision was whether DI should be protected as a cost center awaiting recovery or repositioned as a revenue-generating unit serving external clients. The risk of delay was existential for the unit; the risk of rushing was to offer immature products that could damage reputation and consume scarce capacity.
Constraints and Trade-offs
Time was constrained, and internal teams were under stress. Turning internal capabilities into market offerings required selecting what could be credibly packaged, what needed adaptation, and what should be dropped. A realistic go-to-market approach had to balance ambition with the organization’s delivery capacity.
Architectural / Strategic Perspective
The effort focused on identifying transferable capabilities, defining minimal product boundaries, and clarifying value propositions and operating assumptions. The aim was to create a coherent external-facing portfolio rather than a list of “things the IT unit has”.
Outcome and Impact
DI’s work was reoriented toward external clients, opening new revenue streams and supporting enterprise sustainability during the crisis. The contribution was formally recognized by management.
Lessons Learned
Crisis pivots work when the organization reduces choices quickly: not every internal asset is a product, and the fastest route to sustainability is a small set of defensible offerings.
Strategy formation and risk posture for an airport enterprise
Strategy formation and risk posture for an airport enterprise
Context
Domodedovo Airport operated in a dynamic aviation environment where strategic decisions must account for market shifts, technology change, and operational risks. Annual strategy work required grounded analysis rather than aspirational planning.
The Decision Challenge
The decision challenge was how to shape strategic directions while remaining resilient to uncertainty. Overconfidence in forecasts can lock an organization into brittle commitments; underinvestment in planning leaves it reacting to threats rather than managing them.
Constraints and Trade-offs
Strategy work had to integrate perspectives across market dynamics, technology evolution, and information/IT management. Risk assessment required balancing likelihood and impact without turning the process into paperwork. Management needed actionable response options, not only a list of threats.
Architectural / Strategic Perspective
The work emphasized decision-ready artifacts: trend analyses connected to operational implications, risk scenarios connected to response plans, and strategic initiatives connected to an enterprise view of capabilities and information management. The focus was on making assumptions explicit so leadership could choose deliberate directions.
Outcome and Impact
Strategic directions and initiatives for the next period were clarified, and the airport’s resilience increased through structured risk assessment and response planning. Leadership gained better inputs for strategic decisions and investment prioritization.
Lessons Learned
Strategy becomes practical when it is coupled with a risk posture: not predicting the future, but preparing decision options for plausible futures.
Loyalty program effectiveness evaluation as a management discipline
Loyalty program effectiveness evaluation as a management discipline
Context
Rostelecom had a loyalty program, but it functioned primarily as a points mechanism with limited segmentation, targeting, or analytics. The organization lacked a clear way to evaluate whether the program improved profitability or merely added operational cost.
The Decision Challenge
The decision challenge was to turn loyalty from a “benefit” into a controllable business instrument by defining how effectiveness is measured and how insights lead to program changes. Without an evaluation method, the organization risks optimizing for activity (points issued) rather than impact (incremental revenue, retention, cross-sell).
Constraints and Trade-offs
Better measurement requires better data discipline: consistent identifiers, clean event capture, and alignment between marketing intent and system behavior. More granular evaluation increases complexity and governance needs, while overly coarse metrics produce misleading conclusions and debates instead of decisions.
Architectural / Strategic Perspective
The work framed effectiveness evaluation as a closed loop: define target behaviors, observe them consistently, attribute outcomes, and adjust rules and offers. Practical system-level changes ensured that required events and indicators could be captured and analyzed in a repeatable way.
Outcome and Impact
A methodology for evaluating loyalty effectiveness was established and enabled through targeted system changes. This provided a basis for new marketing initiatives and contributed to revenue and profit growth through more disciplined additional sales efforts.
Lessons Learned
Loyalty programs scale in value only when measurement becomes a first-class capability—otherwise the organization can’t tell whether it is buying retention or just subsidizing existing behavior.
Data management platform architecture to productize telecom data
Data management platform architecture to productize telecom data
Context
Rostelecom generated large volumes of data through core telecom services. The organization saw the opportunity to turn that data into internal decision support and external products, but that required a coherent infrastructure and operating model beyond ad-hoc analytics.
The Decision Challenge
The decision was whether to scale data usage through a platform approach or through isolated solutions for each use case. Isolated solutions can produce quick wins, but they accumulate duplicated onboarding work, inconsistent definitions, and growing governance risk. A platform approach requires higher upfront clarity and prioritization.
Constraints and Trade-offs
Different consumers demand different SLAs and governance controls. A generic platform without prioritization risks becoming an expensive “warehouse of everything”; a narrow platform risks constraining future product ideas. The platform also needed to align with the operating reality of the Data Lab function.
Architectural / Strategic Perspective
The work structured the future platform across business architecture, information concepts, and the data layer—explicitly connecting data suppliers, processing responsibilities, and consumption patterns. The emphasis was on making the roadmap practical: what must be standardized early, and what can evolve as products prove demand.
Outcome and Impact
An architectural package for a DMP and a business-driven implementation direction were established and handed over for implementation, enabling the organization to pursue multiple data-based products and build a longer-term foundation for monetizing insights.
Lessons Learned
The most valuable data platform outcome is not a repository; it is a repeatable way to onboard data and turn it into governed products without reinventing definitions every time.
Simplifying inter-operator settlement accounting under complex offsets
Simplifying inter-operator settlement accounting under complex offsets
Context
Rostelecom’s interactions with other operators involved complex multi-party service supply and debt offset schemes. Settlement reconciliation was slow, error-prone, and paper-heavy, consuming significant operational effort and delaying the availability of funds.
The Decision Challenge
The decision challenge was how to simplify settlements without losing correctness: whether to continue with incremental process improvements or to introduce a more structured settlement registration and reconciliation model. Errors at this layer are expensive—financially and in partner relationships—so “speed” without control would be a false win.
Constraints and Trade-offs
Multiple counterparties and non-trivial offset rules create edge cases that are difficult to resolve manually. Formalizing the model improves accuracy and reduces effort, but it requires agreement across internal stakeholders and partners. Exploring alternative technology (a distributed ledger POC) could increase transparency but introduces adoption and governance complexity.
Architectural / Strategic Perspective
The work focused on making settlement events and obligations explicit: standard representations, controlled reconciliation steps, and clear responsibility boundaries. The alternative approach using distributed registration was explored as a way to reduce disputes and improve traceability, with attention to where such an approach would be justified.
Outcome and Impact
A concept and agreed direction for inter-operator interaction architecture were established, with a documented solution ready for implementation. The expected benefits included thousands of man-hours saved per year and significant error-driven loss avoidance.
Lessons Learned
Multi-party settlements improve when reconciliation is treated as a shared model—with explicit events, obligations, and traceability across parties—rather than as endless exception handling.
Debtor notifications as a lever to reduce accounts receivable
Debtor notifications as a lever to reduce accounts receivable
Context
Rostelecom faced growing accounts receivable, reducing operational flexibility and tying up funds. The existing debtor-informing practice relied on manual reconciliation statements and email correspondence, which was slow, inconsistent, and expensive to run.
The Decision Challenge
The decision challenge was whether to treat receivables as a purely financial control problem or to address it as a communication and behavioral problem: timely, accurate notifications that change client behavior. If approached incorrectly, automation could increase disputes and dissatisfaction, while manual processes could not scale to the needed coverage.
Constraints and Trade-offs
Accuracy and timing were both critical: wrong or late notifications undermine trust and can increase operational load. The organization needed a consistent set of notification rules without building a fragile web of exceptions. The solution also had to reduce manual effort in reconciliation and paperwork, not shift it elsewhere.
Architectural / Strategic Perspective
The approach framed notifications as a governed service: clear event triggers (debt conditions), standardized content rules, and traceability from notification back to financial facts. This reduced ambiguity in how debt is determined and ensured the communication process remained auditable.
Outcome and Impact
A unified notification approach and solution architecture were established and used for implementation. Accounts receivable decreased threefold, and the organization reduced time spent on reconciliation and paper/email handling, producing a material economic effect.
Lessons Learned
Receivables reduction is often achieved not by stronger collections, but by making the organization’s expectations legible and timely—so that paying becomes the default, not a negotiation.
B2B multichannel communications capability for targeted outreach
B2B multichannel communications capability for targeted outreach
Context
Rostelecom’s communication with client organizations lacked a consistent mechanism for segmentation and targeted outreach. Without a managed approach, outreach was either broad and noisy or slow and manual, limiting cross-sell and retention opportunities.
The Decision Challenge
The decision was whether to treat B2B communications as campaign-by-campaign work or to establish a reusable capability with clear segmentation rules and controlled distribution. A poor decision would either increase operational burden (if overly manual) or introduce communication risk (if automated without governance).
Constraints and Trade-offs
B2B communications require careful audience definition, approvals, and traceability to avoid damaging relationships. Scaling outreach depends on standardizing rules for recipient selection, content approval, and channel execution, but standardization can reduce flexibility for unique account situations.
Architectural / Strategic Perspective
The solution was structured around a governed communication pipeline: how segments are defined, where recipient data is sourced, how approvals are recorded, and how distribution is run across channels. Documentation was treated as a risk-reduction mechanism—making rules explicit so implementation effort and misinterpretation risk drop.
Outcome and Impact
An architecture and documentation package for a multichannel B2B communication system clarified how targeted mailings could be run safely. After implementation, the organization gained the ability to run segmented outreach that supported additional sales and improved customer experience.
Lessons Learned
Communication automation only scales when the organization is willing to formalize its rules—especially approvals and recipient logic—so that speed does not come at the cost of trust.
Post-launch audit and recovery plan for corporate data storage
Post-launch audit and recovery plan for corporate data storage
Context
Rostelecom had launched a unified corporate data storage system (EKHD) and then encountered visible operational shortcomings: unclear sources, incorrect processing, disorder in storage practices, and missed SLAs. The investment was at risk of becoming a cost center rather than a decision-support foundation.
The Decision Challenge
The decision challenge was whether to continue investing in a system that was not meeting expectations, and if so, what to change first: technology, data governance, operating processes, or all of the above. Misdiagnosis would either lead to further sunk cost or to superficial fixes that do not restore trust in data.
Constraints and Trade-offs
The system was already in production, so remediation had to preserve continuity for business users. Improvements needed to address both technical and organizational causes, and sequencing mattered: tightening governance without fixing broken pipelines creates frustration; changing technology without clarifying ownership recreates the same disorder on a new platform.
Architectural / Strategic Perspective
The audit linked observed problems to an explicit model of sources, flows, storage zones, and ownership responsibilities. Recommendations treated data as a lifecycle-managed asset: clear onboarding rules, controlled transformations, SLA-backed delivery processes, and governance that makes accountability visible.
Outcome and Impact
The assessment enabled the organization to correct a costly initiative and restore value. Storage costs were reduced by 15%, report preparation time decreased by 4–5×, and the platform became a more reliable basis for management decisions and marketing operations.
Lessons Learned
Large data platforms fail when accountability is diffuse. Recovery starts when the organization can point to specific ownership and lifecycle rules—not just to “better technology.”
Establishing a marketing data analytics subdivision
Establishing a marketing data analytics subdivision
Context
Rostelecom needed to use large-scale behavioral data (visited sites, interests, web activity) to strengthen marketing outcomes: more precise targeting, timely churn response, and new data-driven products. The gap was not only technical—there was no dedicated operating model for turning this data into repeatable business capability.
The Decision Challenge
The decision was whether to treat behavioral data as a byproduct of telecom services or as a strategic asset that justifies a dedicated organization, tools, and governance. Creating a new subdivision is costly and politically sensitive; failing to do so risks leaving valuable data unused and limiting the company’s marketing competitiveness.
Constraints and Trade-offs
The subdivision needed a clear mandate and measurable outcomes, otherwise it would become an “analytics lab” without business pull. Using previously ignored data required agreement on ownership and quality expectations. Building a broad platform too early risked wasted effort; focusing too narrowly risked missing future product opportunities.
Architectural / Strategic Perspective
The work framed the subdivision as a capability portfolio: behavior analysis, segmentation, omnichannel activation, and recommendations as connected decision loops. The emphasis was on defining responsibilities, interfaces to data suppliers/consumers, and metrics that let leadership assess whether the function is producing business value.
Outcome and Impact
A new subdivision was created with analysts, project managers, and technical specialists, enabling systematic use of previously untapped behavioral data. The capability became a foundation for multiple data-driven products, including targeted advertising and recommendation-driven initiatives.
Lessons Learned
Data organizations succeed when they are designed as product functions—with clear outcomes and decision rights—rather than as a collection of tools and experiments.
EA baseline and transformation roadmap for managed growth
EA baseline and transformation roadmap for managed growth
Context
Rostelecom.Restream was expanding and needed growth to remain manageable rather than accidental. Leadership required a clear view of the current enterprise state and a roadmap that could guide change decisions across processes, systems, and technology.
The Decision Challenge
The central decision was how to translate a broad ambition (“grow”) into an actionable transformation sequence. Without a shared baseline and target direction, initiatives compete, dependencies become hidden, and change becomes expensive and risky to coordinate.
Constraints and Trade-offs
The assessment had to balance completeness with usefulness: documenting everything delays decisions, but shallow documentation produces a roadmap that cannot be trusted. Stakeholder perspectives differed across organizational levels, requiring alignment on what matters most for near-term decisions versus long-term evolution.
Architectural / Strategic Perspective
The work structured the enterprise into a baseline view and a target direction, with explicit dependencies and phased steps. The focus was on making trade-offs visible—sequencing, ownership, and implications across business architecture and enabling systems—so leadership could make informed commitments.
Outcome and Impact
An EA baseline and transformation roadmap were established, providing management with a shared foundation for strategic and organizational decisions and a clearer path for subsequent change implementation.
Lessons Learned
Roadmaps become valuable when they shift conversations from “what to build” to “what sequence of decisions reduces risk while keeping the organization able to move.”
Enterprise storage option selection under mixed data needs
Enterprise storage option selection under mixed data needs
Context
Rostelecom.Restream worked with growing data volumes and a mix of structured and unstructured datasets. Different departments had different views on storage and processing needs, which created fragmentation risk and made “one-size-fits-all” decisions hard to justify.
The Decision Challenge
The decision was how to select an enterprise storage direction that balanced reliability, accessibility, and performance without overpaying or locking the organization into a mismatched approach. The risk of getting it wrong was both financial (unjustified spend) and operational (slow processing, reduced availability, inconsistent practices across teams).
Constraints and Trade-offs
Data types had different lifecycles and access patterns, which implied different storage strategies. Centralization improves governance and efficiency, but it can reduce team autonomy if it forces a single model onto all workloads. The selection needed to remain explainable to an architectural committee and actionable for implementation.
Architectural / Strategic Perspective
The work organized the problem around data categories and lifecycles, then translated those into requirements and constraints for storage capabilities. Options were evaluated by explicitly comparing advantages and disadvantages, focusing on controllability and fit rather than claiming a universally “best” choice.
Outcome and Impact
Balanced storage options were presented with clear trade-offs, enabling a defensible selection. The organization improved expectations around reliability and availability and avoided unjustified costs by aligning storage choices with actual data lifecycles.
Lessons Learned
Storage decisions are rarely about capacity; they are about making lifecycle assumptions explicit so that the organization can govern data consistently as volumes and use cases evolve.
Data lake presale and solution defense for an oil & gas enterprise
Data lake presale and solution defense for an oil & gas enterprise
Context
Gazprom Neft needed to work with large, heterogeneous datasets across fuel supply and sales and related products. Existing approaches struggled with scale and variety, limiting the organization’s ability to extract insights and identify new profit opportunities.
The Decision Challenge
The decision challenge was to frame a “data lake” not as a technology trend but as a coherent capability with clear business cases, costs, and implementation risks. Presale success depended on translating data ambitions into a defendable architecture and a credible delivery path under competitive scrutiny.
Constraints and Trade-offs
Large data initiatives fail when they promise universal value without prioritization. The proposal needed to balance platform generality with concrete use cases and to set expectations around governance, data onboarding effort, and time-to-value. Competitive tender conditions raised the bar for clarity and justification.
Architectural / Strategic Perspective
The solution was structured around sources, ingestion patterns, storage and processing responsibilities, and consumption paths for analytics. Emphasis was placed on explaining how the platform would be governed and how it would enable business units to move from data capture to repeatable insight generation.
Outcome and Impact
Customer requirements were analyzed, a competitive solution concept and proposal were prepared and presented, and the solution was successfully defended in a tender process. The presale work established a strong basis for subsequent implementation discussions.
Lessons Learned
In presale for data platforms, credibility comes from acknowledging constraints up front—especially governance and onboarding effort—and showing how value emerges in stages rather than all at once.
Audit of reporting interface layer and data marts
Audit of reporting interface layer and data marts
Context
Rostelecom.Restream depended on an interface layer and data marts to make operational and analytical data usable for business teams. The existing solution required review: misalignment with business needs, performance issues, or unclear ownership patterns can turn reporting into a bottleneck.
The Decision Challenge
The decision was how to stabilize information access: whether to keep extending the existing layer with tactical fixes or to re-establish a coherent model of what data products exist, who owns them, and how they are consumed. A poor approach would prolong ambiguity and raise the cost of every new report or change request.
Constraints and Trade-offs
Business units depend on reporting while the underlying data landscape continues to evolve. Increasing rigor in data marts improves quality and performance, but it also requires tighter governance and a clearer data lifecycle. The work had to produce actionable documentation that engineering teams could use, not just observations.
Architectural / Strategic Perspective
The audit focused on system boundaries, data flows, and the mapping between business questions and data products. The goal was to reduce “unknowns”: clarify bottlenecks, document dependencies, and establish requirements for change that align business intent with technical feasibility.
Outcome and Impact
A comprehensive analysis of the current solution and a documentation package for required changes were prepared, creating a stable basis for improving data accessibility and reducing risk in subsequent enhancements.
Lessons Learned
Reporting platforms fail quietly: not by crashing, but by making every new decision slower. Clear data product boundaries and ownership are often the highest-leverage fix.
Traffic analytics and targeting capability for new revenue streams
Traffic analytics and targeting capability for new revenue streams
Context
Rostelecom.Restream sought profit growth and considered targeted advertising on owned resources as a viable path. That direction required turning user traffic and interest signals into segments and actionable targeting decisions, not just collecting logs.
The Decision Challenge
The decision was how to structure a capability that is commercially useful while remaining defensible: segmenting users and inferring interests can create business value, but it also amplifies risks around data quality, explainability, and operational governance. A weak foundation would produce targeting that cannot be trusted and a business model that does not scale.
Constraints and Trade-offs
Multiple analytical steps (identity resolution, segmentation, interest graph) introduce compounding error. Increasing sophistication improves potential uplift but raises operational and reputational risk if the logic is opaque. The system needed to support both business needs (targeting and recommendations) and the organization’s ability to govern and evolve the capability.
Architectural / Strategic Perspective
The work framed the solution as a decision pipeline: from traffic signals to identity to segment membership to targeting actions. The focus was on clear module boundaries, explicit requirements for data inputs/outputs, and traceability—so commercial decisions remain explainable even as models and rules evolve.
Outcome and Impact
A traffic analysis and targeting system went live, enabling a new targeted advertising business line and supporting recommendation capabilities. The organization gained a scalable foundation for monetizing owned traffic through segmented communication.
Lessons Learned
Monetization of user data is less about algorithms than about governance: when the organization can explain, control, and iterate the logic safely, revenue becomes repeatable rather than opportunistic.
Fuel station management system replacement with integration and migration
Fuel station management system replacement with integration and migration
Context
A fuel station network needed to modernize its operational backbone for station management. The existing setup limited efficiency and made integration with adjacent capabilities (accounting, loyalty, payments, reporting) harder than it should be.
The Decision Challenge
The decision was whether to keep patching legacy processes or to move to a new management backbone while protecting operational continuity. For retail fuel operations, disruptions translate directly into lost revenue, so the migration approach mattered as much as the target state.
Constraints and Trade-offs
Integration surfaces are extensive in station operations, and historical data is operationally relevant. A “big bang” approach reduced time spent in dual-running but increased outage risk; a phased approach lowered risk but required careful control of interfaces and data consistency during migration.
Architectural / Strategic Perspective
The work centered on defining stable station-management capabilities and integration contracts, then planning migration so that business operations remain explainable throughout the change. Data migration was treated as an integrity problem (definitions, mappings, validation) rather than a file transfer.
Outcome and Impact
A fuel station management system was put in place with the required integrations and completed data migration, improving transparency and manageability of station operations and reducing manual effort caused by fragmented tooling.
Lessons Learned
In retail operations, modernization succeeds when migration is designed as a business continuity plan—with explicit risk containment and verifiable data integrity at each step.
Omnichannel client notifications under compliance and volume constraints
Omnichannel client notifications under compliance and volume constraints
Context
VTB Pension Fund needed to communicate with clients reliably and at scale. Communication processes were fragmented: no unified recipient lists, limited segmentation, and inconsistent scenarios, which made timely and accurate notifications difficult.
The Decision Challenge
The decision was whether to keep operating as a set of ad-hoc mailings or to establish a managed communication capability across channels. The cost of getting it wrong was both operational (missed or late messages at scale) and reputational, especially when clients depend on timely information about their accounts.
Constraints and Trade-offs
Multiple channels introduced compliance, deliverability, and consistency constraints. Higher automation improved speed but required strict governance around templates, approvals, and segmentation rules to prevent errors. The organization needed a process that remained understandable to business owners, not only to IT.
Architectural / Strategic Perspective
The work approached communication as a governed pipeline: audience definition, scenario design, message templating, approvals, and controlled execution across channels. The goal was predictable behavior—traceable rules, repeatable campaigns, and clear ownership—so volume could increase without increasing failure rates.
Outcome and Impact
The system supported hundreds of thousands of messages per week. Message preparation time decreased tenfold, and event-based mailings that previously took up to two weeks were completed in one day, improving communication quality and reducing process confusion.
Lessons Learned
At scale, “messaging” is not content production; it is a decision system where governance, segmentation rules, and operational discipline determine whether automation is safe.
Monitoring and predictive maintenance concept for retail climate equipment
Monitoring and predictive maintenance concept for retail climate equipment
Context
X5 Retail Group faced product losses and elevated electricity costs due to inconsistent temperature control in stores. Equipment failures were handled reactively, with limited ability to plan maintenance or understand systemic drivers of downtime and spoilage.
The Decision Challenge
The decision was how to structure an investment in monitoring and predictive maintenance so that it produces measurable impact (including a 10% electricity cost reduction target) without creating a solution that stores cannot operate consistently. The risk of choosing poorly was high: either continued losses from downtime/spoilage or a costly initiative with unclear economics.
Constraints and Trade-offs
Retail environments impose practical constraints: diverse store formats, existing equipment heterogeneity, and limited tolerance for operational disruption. Vendor selection and architecture needed to balance speed to rollout against long-term flexibility and data ownership. Predictive capabilities depend on data quality and consistent instrumentation, which are costly to standardize.
Architectural / Strategic Perspective
The work compared credible architectural paths and made the economic logic explicit: what data is needed, where it is captured, how it is governed, and how insights become operational decisions (alerts, maintenance planning, reporting). Options were evaluated as different trade-offs between implementation complexity, controllability, and expected value.
Outcome and Impact
Two architectural options, a vendor evaluation approach, and a phased roadmap were prepared to support a tender decision. The organization gained a clear basis for selecting a path toward reduced losses, more predictable maintenance, and measurable energy efficiency improvements.
Lessons Learned
Predictive maintenance programs are won or lost in the operating model: if stores cannot trust and act on signals consistently, analytics never turns into savings.
Carsharing service launch with cloud-based fleet operations
Carsharing service launch with cloud-based fleet operations
Context
CAR5 planned a carsharing launch from zero, requiring an operational backbone for fleet availability, customer interaction, and integration with in-car devices and external service providers. The viability of the business depended on reliability and the ability to scale with growth in users and vehicles.
The Decision Challenge
The central decision was how to design for reliability and scalability before real-world load patterns were known. A minimal build risked rework and fragility under growth; a heavy upfront design risked overinvestment and slow time-to-market.
Constraints and Trade-offs
The solution needed dependable signals from vehicles and predictable behavior across multiple external dependencies. Operational transparency mattered as much as features: the business needed to understand what the fleet was doing and why. Moving to a cloud environment improved resilience but introduced new operational disciplines and cost controls.
Architectural / Strategic Perspective
The work treated the platform as a coordination system: clear domain boundaries (customer actions, fleet state, payments, device telemetry), explicit integration contracts, and an operating model that anticipates partial failures. The architecture emphasized observability and fault containment so incidents stay localized and operational decisions remain possible during disruptions.
Outcome and Impact
A carsharing service went live with web and mobile channels and an integrated fleet management backbone. Cloud-based infrastructure increased reliability and improved operational transparency, creating a scalable base for growth.
Lessons Learned
Early-stage platforms succeed when reliability is designed as a business capability—so that the organization can keep making decisions even when parts of the ecosystem misbehave.
Architecture audit and standards-aligned documentation for PSMS software
Architecture audit and standards-aligned documentation for PSMS software
Context
Wincor Nixdorf had an operational petrol station management system in the field, but the architectural knowledge and documentation were not sufficiently current or standardized. This created support and evolution risk and complicated alignment with local and European expectations for documentation quality.
The Decision Challenge
The decision was whether to treat documentation as a compliance artifact or as a control mechanism that reduces operational and delivery risk. In mature, already-running software, gaps in architectural understanding translate into slower incident resolution, fragile integrations, and costly change.
Constraints and Trade-offs
The work had to describe an existing reality rather than a greenfield design. Over-documentation would be expensive and quickly stale; under-documentation would fail to support compliance and change. The emphasis needed to be on system boundaries, responsibilities, integrations, and operational characteristics.
Architectural / Strategic Perspective
The audit focused on making implicit decisions explicit: how the system is decomposed, where data moves, and where constraints and risks accumulate. Documentation was structured to support both engineering work (change planning, integration safety) and organizational needs (common vocabulary, repeatable reviews, standards alignment).
Outcome and Impact
An architectural audit clarified the current state and risks of the PSMS software, and a complete documentation set was established in a standards-aligned form. As a result, the system became easier to support and evolve, and the organization reduced the risk associated with undocumented dependencies.
Lessons Learned
In long-lived systems, documentation is not a narrative of work—it is a mechanism for preserving decision intent so that future change does not turn into accidental redesign.
Medical analytics for athlete health assessment and planning
Medical analytics for athlete health assessment and planning
Context
The Federal Medical-Biological Agency needed a more systematic way to collect and use medical data related to athletes’ health assessments. Without a consolidated analytical view, forecasting performance trends and adjusting training plans relied too heavily on fragmented information and individual interpretation.
The Decision Challenge
The decision was how to turn medical assessments into actionable planning input without overstating certainty. A system that only stores data does not change outcomes; a system that claims predictive power without disciplined assumptions creates false confidence. The challenge was to support informed judgment under medical and performance constraints.
Constraints and Trade-offs
Medical data sources and assessment methods vary, and adoption depends on usability for clinicians and coaches. The solution needed to support analytical insights while maintaining traceability back to assessments. Speed and breadth of data coverage had to be balanced against consistent interpretation and reporting.
Architectural / Strategic Perspective
The work emphasized an information architecture where assessments, indicators, and planning outputs are explicitly related. Analytical components were treated as decision support: transparent inputs, clear outputs, and repeatable reporting rather than opaque “predictions”. Integration of sources was approached as an operating discipline—consistent capture and curation before analytics.
Outcome and Impact
FMBA gained a medical information and analytical system that supports forecasting and provides structured input into training planning based on health assessments. The organization’s ability to work with athlete medical data became more consistent and repeatable.
Lessons Learned
In health-related analytics, the most important outcome is not a forecast—it is a shared, traceable basis for decisions that remain accountable to the underlying assessments.
Loyalty platform for a fuel retail network
Loyalty platform for a fuel retail network
Context
Gazprom Neft’s fuel retail network needed loyalty to function as a business lever rather than a simple points accumulator. Without a coherent platform, personalization, measurement of campaign impact, and consistent customer experience were limited.
The Decision Challenge
The decision was whether to keep loyalty as a lightweight marketing tool or treat it as a customer and revenue management capability with enterprise-grade data and operational discipline. Getting it wrong would either cap growth (if too simplistic) or create a costly program that cannot be operated consistently across channels (if too complex too early).
Constraints and Trade-offs
The platform had to work across many retail locations and integrate into daily point-of-sale operations without adding friction. More personalization and analytics increased complexity and data demands, while a simpler design reduced the ability to learn and adapt. The program needed rules that could be explained to customers and staff, not only to engineers.
Architectural / Strategic Perspective
The work treated loyalty as a system of decisions: how customers are identified, how benefits are earned and redeemed, and how campaigns are evaluated. That required consistent customer/account definitions, clear rule governance, and reliable feedback loops from transaction data to marketing decisions.
Outcome and Impact
A comprehensive loyalty system was established for the retail chain. Participation grew from 1M to 4.5M, and marketing effectiveness improved through better segmentation and measurable campaign execution.
Lessons Learned
Loyalty becomes valuable when it shifts from “points accounting” to a disciplined learning loop—where customer behavior, offers, and outcomes connect in a way the organization can trust.
Corporate cashless fuel payments with fraud reduction
Corporate cashless fuel payments with fraud reduction
Context
Gazprom Neft managed cashless fuel payments for a very large base of corporate customers (70,000+ legal entities). Paper fuel coupons and manual reconciliation created operational drag and opened space for fraud, producing direct losses and slow settlement cycles.
The Decision Challenge
The core decision was whether to keep improving controls around a paper-based model or to move the settlement mechanism onto an instrument that supports traceability and enforceable rules. A wrong choice risked continued fraud exposure and an ever-growing reconciliation effort that would not scale with the customer base.
Constraints and Trade-offs
A change in payment instrument affected security, customer experience, and operational processes (issuance, blocking, accounting, dispute handling). Anti-fraud measures had to improve materially without turning the solution into a high-friction process for legitimate customers. Scale meant that edge cases could not be handled manually.
Architectural / Strategic Perspective
The platform was framed as a control system: clear lifecycle management for the payment instrument, enforceable rules around transactions, and reconciliation as a repeatable process rather than an investigation. Interfaces to adjacent enterprise systems needed to preserve auditability so that operational decisions and financial outcomes stayed explainable.
Outcome and Impact
A cashless settlement platform replaced paper coupons with cards, enabling automated settlements with 70,000+ legal entities. Reconciliation time was reduced sixfold, fraud-related losses fell tenfold, and the client formally recognized the business impact.
Lessons Learned
Fraud reduction at scale is rarely a single “security feature”; it comes from designing the operating model so that traceability and control are built into how the business runs.
ERP standardization for operational transparency in a pre-sale period
ERP standardization for operational transparency in a pre-sale period
Context
Rostelecom.SkyLink entered a pre-sale phase where manageability and transparency mattered as much as operational performance. Fragmented operational data and non-standard reporting slowed decision-making and made it harder to demonstrate control over the business.
The Decision Challenge
The key decision was whether to invest in standardization and a unified operational backbone under time pressure. A conservative path (minor fixes around legacy tools) preserved short-term comfort but risked leaving the organization with the same opacity at the worst moment. A more ambitious path improved transparency but required coordinated change and disciplined scope control.
Constraints and Trade-offs
The work had to stabilize reporting and data access without disrupting ongoing operations. Integration with billing and support processes increased complexity: the system needed consistent boundaries between operational transactions, customer-facing billing, and user support. The pre-sale context favored predictability and auditability over customization.
Architectural / Strategic Perspective
The approach centered on a single operational “source of truth” with clear integrations to adjacent systems. Reporting was treated as a management product: consistent definitions, traceability back to operational facts, and repeatable generation. Supportability was addressed as part of the operating model by establishing a clear path for issues and changes.
Outcome and Impact
The organization gained timely access to operational data through a unified ERP backbone, with integration to billing and an established user support channel. Standardized reporting increased transparency and improved business manageability during the pre-sale period.
Lessons Learned
In pre-sale environments, enterprise systems are less about features and more about trust: the ability to explain the business with consistent data, repeatable reports, and controlled change.
Unified payroll and HR operating model across branches
Unified payroll and HR operating model across branches
Context
Rostelecom.SkyLink’s distributed branch network relied on non-uniform payroll and HR practices. Differences in accrual logic and incentive schemes created inconsistencies, increased manual checks, and made personnel costs difficult to plan and control.
The Decision Challenge
The decision was whether to prioritize local autonomy or enterprise consistency in payroll and HR accounting. Fragmentation reduced comparability and increased error risk; strict standardization risked friction where incentive schemes and operational realities differed by branch.
Constraints and Trade-offs
A unified approach needed to support existing compensation logic while making the rules explicit and auditable. Integration with budgeting meant that HR data could no longer be treated as “back office”; it became an input into financial decisions. Adoption required keeping the experience workable for a broad user base (50+ users) without building exceptions into the core logic.
Architectural / Strategic Perspective
The work focused on defining stable “rules of record” for payroll, incentives, and personnel events, and on connecting those rules to financial planning. The emphasis was on reducing ambiguity through common definitions, consistent approval paths, and predictable outputs for budgeting and reporting.
Outcome and Impact
A single payroll and motivation system was put in place across branches and connected to the budgeting system, improving transparency of personnel costs and reducing discrepancies in accruals. An HR system went into use for 50+ users, stabilizing day-to-day HR operations.
Lessons Learned
When payroll becomes a planning input, consistency is a governance decision—not an IT feature. The “system” succeeds only when the organization is willing to make its compensation logic explicit.
Consolidated accounting and inventory across legal entities
Consolidated accounting and inventory across legal entities
Context
Rostelecom.SkyLink operated through multiple legal entities with fragmented accounting and inventory practices. Disparate data made consolidated reporting slow and unreliable and weakened integration with planning and control functions.
The Decision Challenge
The core decision was how far to push unification: whether to accept “local truth” in each entity and stitch reports together later, or to enforce shared definitions and workflows so that consolidation becomes routine. A poor choice would either stall adoption (if overly rigid) or preserve the same transparency problems under a new label (if overly permissive).
Constraints and Trade-offs
Unification required aligning accounting policies and inventory rules while respecting legal-entity differences. Faster rollout favored minimal change, but long-term transparency depended on disciplined data standards and consistent operating procedures. Integration with existing planning processes added pressure to define stable interfaces and ownership.
Architectural / Strategic Perspective
The work treated accounting and inventory as enterprise data products: a single set of definitions, controlled master data, and predictable aggregation paths to consolidated views. The emphasis was on reducing reconciliation surfaces—fewer handoffs, fewer transformations, and fewer “special cases” that only exist in spreadsheets.
Outcome and Impact
Accounting and inventory management were unified across legal entities, enabling transparent consolidated reporting and making integration with planning systems feasible. Operational effort shifted away from manual consolidation toward routine, repeatable controls.
Lessons Learned
For multi-entity organizations, the hardest part is not the system choice but agreeing on what “consistent data” means in practice—and being explicit about where differences are legitimate and where they are just inherited noise.
Internal budgeting and financial control
Internal budgeting and financial control
Context
Rostelecom.SkyLink relied on budgeting and internal financial control processes that were slow and opaque. Budget preparation could take up to six months, which limited the organization’s ability to respond to change and reduced confidence in management reporting.
The Decision Challenge
The central question was whether budgeting should remain a periodic administrative exercise or become a management control loop supported by consistent data and rules. Getting it wrong risked locking the company into long planning cycles, weak cost discipline, and decisions driven by incomplete or late information.
Constraints and Trade-offs
The work had to reconcile different expectations across finance and management while keeping day-to-day operations running. Standardization improved comparability and control, but it reduced local flexibility and forced explicit choices about definitions, approval flows, and reporting granularity.
Architectural / Strategic Perspective
The problem was framed as an end-to-end decision system: how plans are created, approved, monitored, and corrected. That required a shared information model for budget items and financial facts, clear ownership of rules, and a consistent path from operational inputs to management views. The emphasis was on making the logic auditable and repeatable rather than relying on individual expertise and manual reconciliation.
Outcome and Impact
Budget preparation time was reduced from six months to two months. Financial transparency improved, enabling more reliable monitoring of financial flows and stronger internal control without increasing the manual reporting burden.
Lessons Learned
This case illustrates that “automation” only matters after the organization agrees on what it wants to control and why; clarity of definitions and decision rights is what makes speed and transparency sustainable.