CRM & Customer Lifetime Value in Banking

How do you develop a complex CRM environment, when part of the knowledge about the existing solution first needs to be reconstructed?

1. Context

The project involved a Customer Lifetime Value / CRM environment for a European bank and covered both ongoing development and maintenance of an existing solution.

Waldemar was responsible for maintaining the solution model in Enterprise Architect, analysing sprint scope, facilitating workshops and reverse-engineering existing CRM functionalities and integrations.

2. Challenge

Systems developed over many years do not always have documentation that accurately reflects their current behaviour.

Before designing a new change, it was therefore necessary to establish:

• how an existing functionality actually worked,
• which components it depended on,
• where system responsibility boundaries were located,
• how a proposed change would affect the existing landscape,
• how to describe the change clearly for both business and development teams.

3. Waldemar’s Role

As a Senior Business–System Analyst, Waldemar was responsible for end-to-end analysis of sprint scope and for maintaining consistency between business requirements, the existing solution model and planned changes.

4. Scope of Analysis

The work included:

• analysis of upcoming sprint scope,
• reverse engineering of existing CRM functionalities,
• integration analysis,
• maintenance of the Enterprise Architect model,
• dependency identification,
• clarification of business requirements,
• preparation of changes for development teams.

5. Methods & Deliverables

The work involved:

• Enterprise Architect models,
• use cases,
• user stories,
• change documentation,
• business and technical workshops,
• as-is analysis,
• reverse engineering,
• end-to-end analysis.

The CV specifically confirms responsibility for maintaining the EA model as well as delivering use cases, user stories and supporting documentation for changes.

6. Stakeholder Collaboration

Workshops were conducted with both business stakeholders and development teams.

This made it possible to compare business expectations with the actual behaviour of the existing solution and identify gaps between the expected and technically feasible scope of a change.

7. Outcome

Each change was supported by clear analytical documentation connecting the existing system, the business requirement and the work of the development team.

Reverse engineering allowed new changes to be designed based on the actual behaviour of the solution rather than outdated assumptions or incomplete documentation.

8. Technologies & Tools

CRM • Customer Lifetime Value • Enterprise Architect • UML • Requirements Engineering • Reverse Engineering

9. Confidentiality

The case study does not disclose the bank’s internal processes, data models, solution architecture or commercially sensitive information.

CTA:
Is your CRM documentation no longer aligned with the system itself? Let’s start with an as-is analysis and reverse engineering.

User Access Management for Finance & Budgeting

How do you translate access policies and governance principles into processes that make sense to users, business stakeholders and IT teams?

1. Context

The project involved User Access Management for finance and budgeting systems within an international organisation.

The scope covered access processes, roles, permission models and governance principles.

Waldemar led the analysis, prepared business and technical documentation, facilitated workshops and supported end-user training.

2. Challenge

Access management sits at the intersection of several areas:

user needs, organisational structure, security requirements, operational processes and system constraints.

Defining who should have access is not enough.

A complete solution must also establish roles, approval paths, access provisioning and removal processes, responsibilities, exceptions and governance across the entire access lifecycle.

3. Waldemar’s Role

Waldemar worked as the Senior Business–System Analyst responsible for UAM analysis, connecting process requirements with role and access models.

4. Scope of Analysis

The scope included:

• access provisioning and modification processes,
• business and system roles,
• permission models,
• approval flows,
• governance,
• ownership and responsibilities,
• exception scenarios,
• the end-user perspective of new access management processes.

5. Methods & Deliverables

Deliverables included:

• process models,
• role and access models,
• business documentation,
• technical documentation,
• training support materials,
• outputs from workshops and brainstorming sessions.

6. Stakeholder Collaboration

The analysis was performed through collaborative workshops.

This ensured that access rules were not designed purely from a technical perspective, but also reflected how users and process owners actually worked with finance and budgeting systems.

7. Outcome

The project resulted in a structured and documented UAM process model, covering roles, access and responsibilities as well as documentation supporting communication of the new processes to end users.

The engagement also included support for user training related to the new UAM processes.

8. Technologies & Tools

User Access Management • Role & Access Models • Governance • Process Modelling • Requirements Engineering

9. Confidentiality

For security reasons, the case study does not describe detailed authorisation mechanisms, permission structures or the client’s system architecture.

CTA:
Designing UAM, RBAC or access governance processes? Let’s translate security requirements into clear processes and access models.

GDPR & Blockchain Platform for the Financial Sector

How do you connect regulatory requirements, distributed architecture and integrations with multiple financial institutions?

1. Context

The engagement covered two significant areas within the financial sector: implementation of GDPR-related regulatory changes and development of a DLT/blockchain platform designed to work with multiple banks.

The solution supported public and private document storage and had to address requirements associated with the “right to be forgotten”.

2. Challenge

The project combined three complex areas:

regulation + inter-organisational integrations + emerging technology.

In a solution involving multiple financial institutions, a legal requirement has to be translated into precise system behaviour, data considerations, integration requirements and test scenarios.

3. Waldemar’s Role

As a Senior Business Systems Analyst, Waldemar was responsible for business and systems analysis, project documentation and technical clarification for both GDPR and blockchain initiatives.

4. Scope of Analysis

The work included:

• analysis of GDPR-driven changes,
• requirements concerning document processing,
• integration of the platform with multiple banks,
• integration-level analysis,
• technical clarification of requirements,
• analytical support for testing activities.

5. Methods & Deliverables

Activities included:

• project documentation,
• business and system requirements,
• integration analysis,
• technical clarifications,
• QA support,
• User Acceptance Testing,
• Business Acceptance Testing,
• ad-hoc analysis.

The CV directly confirms involvement in both integrating the blockchain platform with multiple banks and supporting QA, UAT and BAT.

6. Stakeholder Collaboration

The project required alignment between regulatory, business and technology perspectives.

A key part of the analyst’s role was ensuring that expected system behaviour was described clearly enough to be consistently interpreted by integration and testing teams.

7. Outcome

The work delivered the documentation and analysis required to support regulatory changes and integration of the DLT solution with financial institutions.

Analytical support during QA, UAT and BAT also helped verify that the implemented solution remained aligned with agreed requirements.

8. Technologies & Tools

GDPR • DLT / Blockchain • Banking Integrations • QA • UAT • BAT • Requirements Engineering

9. Confidentiality

The case study does not disclose solution topology, banking interfaces, processed data or detailed security mechanisms.

CTA:
Does your project combine regulatory requirements with integrations across multiple organisations? Let’s turn regulatory obligations into clear system requirements and verification scenarios.

Mission-Critical System in a Regulated Environment

How do you conduct systems analysis when security and unambiguous documentation are integral parts of the solution itself?

1. Context

The project involved a web application designed for border guard services.

It was developed in a regulated, security-focused environment and delivered iteratively using Agile practices.

2. Challenge

In mission-critical systems, an ambiguous requirement is not merely a project management issue.

It may affect system security, user behaviour, testing and the decisions made by implementation teams.

Maintaining consistency between business documentation, the system model and the scope of subsequent sprints was therefore particularly important.

3. Waldemar’s Role

Waldemar was responsible for preparing business and technical documentation, maintaining the solution model in Enterprise Architect and providing analysis for subsequent Agile sprint scopes.

4. Scope of Analysis

The work included:

• business requirements,
• system requirements,
• sprint scope analysis,
• solution modelling,
• analysis of dependencies between system components,
• preparation of analytical information for delivery teams.

5. Methods & Deliverables

Key deliverables included:

• business documentation,
• technical documentation,
• the solution model in Enterprise Architect,
• analyses supporting successive Agile sprints.

6. Stakeholder Collaboration

The engagement required close alignment between business and technical analysis.

The analyst’s role was to maintain a common language between operational requirements and their representation within the system solution.

7. Outcome

The result was a set of documentation and a maintained solution model supporting iterative development of the application.

In a security-sensitive environment, particular value came from providing a clear, structured and traceable description of the solution and its requirements.

8. Technologies & Tools

Enterprise Architect • Web Applications • Agile • Business & Systems Analysis • Technical Documentation

9. Confidentiality

Due to the nature of the project, publicly available information is limited to the type and scope of analytical work performed. Functional details, architecture and security mechanisms are not disclosed.

CTA:
Working on a regulated or mission-critical system? Let’s discuss how to structure requirements, models and documentation for reliable delivery.

Pharma & Banking • CRM • ERP • Sprint Analysis

Project Overview

Analysis of a complex CRM/ERP environment covering both ongoing system evolution and preparation of clearly defined scope for development teams.

My Contribution

The work included:

• maintaining the Enterprise Architect model,
• end-to-end analysis of sprint scope,
• workshops with business and development teams,
• reverse engineering of existing CRM capabilities,
• integration analysis,
• preparation of use cases and user stories,
• supporting documentation for planned changes.

Business Perspective

The objective was to reduce ambiguity between business expectations, existing system behaviour and implementation scope.

Rather than treating individual requirements in isolation, the analysis considered the wider CRM and ERP landscape and the impact of proposed changes across connected functionality.

Methods & Tools

CRM • ERP • Enterprise Architect • Requirements Engineering • Reverse Engineering • Agile

Banking • CRM • Customer Lifetime Value • R&D & Maintenance

Project Overview

Development and maintenance of a Customer Lifetime Value CRM environment for a European banking organisation.

The project combined ongoing product development with analytical work required to understand and evolve an established CRM landscape.

My Contribution

Responsibilities included:

• maintaining the CLV/CRM model in Enterprise Architect,
• analysing sprint scope end to end,
• leading workshops,
• reconstructing existing CRM functionality,
• analysing integrations,
• preparing use cases, user stories and supporting documentation.

Business Perspective

A significant part of the work involved converting knowledge embedded in an existing system into structured analytical documentation that could support future changes.

Methods & Tools

CRM • Customer Lifetime Value • Enterprise Architect • UML • Reverse Engineering • Workshops

Pharma • Global Integrations • Canonical Model • EMEA/APAC

Project Overview

Long-term participation in a global pharmaceutical integration programme comprising multiple implementation waves, sub-projects and enterprise systems.

My Contribution

As a Core Senior Business–System Analyst, I was responsible for:

• the analytical perspective of the canonical integration model,
• Change Request analysis,
• impact assessments,
• integration-level optimisation,
• business and technical documentation,
• workshops, discovery sessions and demonstrations,
• JIRA requirements and backlog management,
• coordination across EMEA and APAC time zones.

Business Perspective

The central challenge was maintaining a reliable view of dependencies across a constantly evolving global integration landscape.

The analytical model provided a common point of reference when assessing how new changes could affect existing systems and integrations.

Selected Deliverables

HLD • BRD • SLA • RFP • Test Plans • Impact Assessments • Integration Models

Pharma • Enterprise Integration • Marketing Technology

Project Overview

Integration of an enterprise pharmaceutical platform with OCE to support marketing-related business scenarios.

My Contribution

The analytical work focused on understanding the business use cases, defining integration requirements and positioning the change within the wider enterprise integration landscape.

Key Areas

• business use-case analysis,
• integration requirements,
• dependency identification,
• impact assessment,
• documentation supporting delivery and testing.

Business Perspective

The project required translating marketing requirements into precise system interactions that could be implemented consistently within an existing enterprise architecture.

Methods & Tools

OCE • Integration Analysis • Requirements Engineering • Enterprise Architecture

The integration is listed among the selected sub-projects of the global pharmaceutical programme.

Pharma • Identity Management • OCE • SailPoint

Project Overview

Integration between OCE and SailPoint supporting the complete user lifecycle.

The scope included lifecycle events such as:

create • activate • deactivate • delete

My Contribution

The work required analysing how user states and identity-management processes should be represented consistently across connected systems.

Key Areas

• user lifecycle analysis,
• system interaction modelling,
• integration requirements,
• state and dependency analysis,
• Change Request and impact assessment support.

Business Perspective

Identity integrations are highly dependent on consistent rules and system states. The analytical goal was to ensure that business lifecycle events translated into unambiguous behaviour across both systems.

Technologies

OCE • SailPoint • Identity Lifecycle • Enterprise Integration

Pharma • Master Data • Reltio • PCS • APAC

Project Overview

Integration between Reltio and PCS deployed across multiple national environments, including markets in Asia-Pacific.

My Contribution

The work supported integration analysis across country-specific implementations while maintaining consistency with the wider enterprise integration model.

Key Areas

• integration dependencies,
• data-flow analysis,
• regional implementation considerations,
• impact assessment,
• analytical documentation.

Business Perspective

Multi-country deployments introduce additional complexity because a common integration model must coexist with local implementation requirements and regional dependencies.

Technologies

Reltio • PCS • Master Data • Enterprise Integrations • APAC

The CV explicitly identifies deployments in several countries, including Taiwan, the Philippines and China.

Pharma • Global Data • Pricing • 50+ Countries

Project Overview

A solution designed to inform pharmaceutical affiliates and global teams about changes in drug prices across more than 50 countries.

Project Context

The solution operated in an international environment where pricing information had to remain understandable and usable across multiple markets.

Analytical Focus

The project required attention to:

• information flows,
• data consistency,
• international business requirements,
• stakeholder communication,
• structured documentation.

Business Perspective

The scale of the project made consistency and clarity of information across countries particularly important.

Domain

Pharmaceutical Pricing • Global Information Management • International Operations

The project is identified in the CV as SARA IRP and covered drug-price change information across 50+ countries.