Programme

Knowledge leaves with people — projects stall, and tasks get lost.
How can business continuity be ensured during analyst rotation?

Based on a real-life case, I will present a five-step knowledge transfer system that delivers a guaranteed result. You will get a clear algorithm that reduces handover time by half and stress levels tenfold. No chaos — just a controlled process.

This talk will be useful for an individual analyst, as preparing a “replacement” is essential for rotation or career progression, as well as for managers and team leads who are responsible for outcomes and cannot afford downtime or a drop in the quality of task execution.

Systems analysts have to explain to stakeholders why it's impossible to simultaneously achieve the ideal properties of a distributed system. In our previous talk at AnalystDays #21, we explored approaches to constraining CAP in disaster scenarios. This time, I propose reflecting on and structuring an approach to analysing PACELC constraints in normal operating scenarios.

You'll learn how these tradeoffs impact data consistency requirements, the choice of architectural patterns, and technology limitations.

This talk will help you better justify design decisions and anticipate the business impact of architectural choices.

In every kingdom of system and business analysis, the elements rage: rivers of treacherous deadlines, whirlwinds of fiery meetings, and avalanches of demands. Even the strongest heroes of analytics are not immune to the charms of procrastination, the poisons of distracted attention, and the ghosts of burnout. These dark forces steal not only time but also the strength of the spirit, depriving us of the energy we need to make great discoveries. 

My talk is an alchemical scroll for those who are ready to regain control of their time. Before you open its pages, you will have to go through a ritual to identify your hidden enemy. Only then will the formulas that turn chaos into order be revealed: potions against procrastination, spells for concentration, and elixirs for reviving motivation. 

You will leave not with an abstract theory, but with personal productivity artifacts that can ignite your inner fire, tame the chaos of your projects, and turn time into a reliable ally.

In many teams, data visualisation comes down to choosing chart types — bar or pie charts — and selecting colours. Reports look neat, the data is correct, yet the business still doesn’t understand what to do with it.

In the talk, I suggest looking at visualisation not as data decoration, but as a decision-making tool. We’ll explore why meaning is often lost even before the first chart even appears, and why no “beautiful visualisation” can help if it’s unclear which management decision should be made based on the report.
I'll show where we most often go wrong:

• designing reports without understanding the decision context,
• answering the question “what does the data look like?” instead of “what is important to notice here?”,
• discussing chart types and techniques instead of meaning and focus.

Representatives of different stakeholders often believe they have different interests in a project.

This frequently leads to conflicts of interest, which in turn creates a whole range of negative effects, increasing the analyst's workload:

• problematic approvals of proposed architectural solutions;
• additional comments during demonstrations of implemented functionality;
• increased criticism of documentation;
• etc.

• techniques that help increase stakeholder loyalty;
• communication mistakes that should be avoided;
• factors that influence stakeholder loyalty;
• how to benefit from a stakeholder’s personal loyalty.

Did you know that AI can help analysts do more than writing requirements, it can also quickly turn them into a clickable UI/UX prototype? That means some problems can be solved much faster than with a long spec and endless review cycles: you can show the interface, walk through key user flows, validate states and error handling, and catch logic gaps before development begins when changes are still cheap.

In this talk, I’ll walk through a practical case study showing how an analyst can use AI to turn requirements into a working prototype, speed up stakeholder alignment, and identify “holes” in logic — not replacing the UI/UX designer, but strengthening requirement quality and communication.

Vibe coding is an actively evolving approach to software development in which AI performs the lion’s share of the work. How is the development of this approach and its associated tools already impacting the role of a systems analyst?

In this talk, using a completed project and the AI-powered code editor Cursor AI as examples, we will explore the opportunities that vibe coding and its tools offer to analysts. What can already be used today and how, what limitations currently exist, and what the future prospects this approach opens up.

Today, a business analyst is someone who helps businesses change. But how should a business analyst themselves change and adapt?

We'll explore two vectors of business analysis development at Gazprombank:

• Standards and Processes.
• People and Culture.

We often complain that clients come to us with solutions instead of clearly defined problems. But if we are honest, we tend to do the same—just more carefully, and under the guise of analysis.

In this talk, we will explore why this happens, even though we repeatedly ask stakeholders to avoid this approach. After all, the first step should always be to formulate the problem properly.

We will then look at how the Theory of Constraints approaches problem framing: what common mistakes to avoid when defining problems, and how to identify the underlying core conflict that drives them.

This talk explores the development prospects of the TypeSpec technology introduced by Microsoft as an alternative to traditional methods for describing data types and APIs.

The author examines the key advantages and limitations of TypeSpec, assessing its potential to become a universal technological notation within modern application ecosystems.

The goal of the talk is to analyse the advantages and disadvantages of TypeSpec compared with existing typing standards such as OpenAPI, JSON Schema, and others. Issues of compatibility with various programming languages, support for modern microservice architectures, and the impact on the API development process.

When should new functionality be implemented within an existing system, and when is it worth extracting it into a separate (micro)service?

In this workshop, we will explore different approaches to decomposing a system into components and answer the following questions:

• what are the criteria for splitting or merging services?
• how do non-functional requirements influence system decomposition?
• what tools can support decision-making beyond Event Storming and DDD?

In the final part, you will apply these ideas to your own project.

Intended for experienced systems analysts at middle+ / senior level.

In this talk, I will show how analysts can simplify their work using large language models. We will discuss which tasks are worth automating with AI, what kind of architecture can be used to solve analytical tasks, and how these approaches function in practice. We will also build an MVP of an AI analyst agent that can later be adapted to different analytical tasks.

The IT recruitment market is experiencing one of its most severe crises: fewer vacancies, higher competition, and job searches stretching over months. But that's not all—your resume is now being evaluated not only by humans, but also by AI agents. 

This talk explores how modern recruitment works, how selection algorithms are configured, and how candidates can adapt: ​​ properly package their experience, pass automated filters, and become visible on the market again.

Metrics are often perceived as reporting. However, when used properly, they become a tool for managing the process.

In this talk, I will share how we introduced metrics into the analysis process — from the initial feeling of lack of transparency in the team’s work to building a system that helps quickly identify bottlenecks and make data-driven decisions.

We will discuss which metrics are truly useful, how to automate their collection, and how to read metrics together to understand the reasons behind changes in the analysis process.

We transferred requirements from scattered documents into a Git repository, where they follow the same rules as code: they have branches, go through reviews, and are compiled into documents automatically. 

In the course of our work, we encountered the fact that a lengthy approval process, lack of traceability to architectural elements, and the absence of a single up-to-date set of requirements led to real knowledge about the product being 'dissolved' across message threads, outdated diagrams, and developers' memory. This pushed us to look for an approach where requirements become the same kind of engineering artefact as code. 

We'll share how we arrived at the “requirements as code” model, built a process from writing in unified templates to approval in Git with the efforts of the entire team (analysts, architects, developers, testers), and continue to optimise this workflow for multiple parallel versions of the product.

“Oh, I get it now!” — a phrase every analyst hopes to hear after someone reads their documentation. In reality, however, it usually ends with a bunch of meetings and follow-up questions.

In this talk, I suggest looking at documentation from an unexpected angle — through the lens of marketing. We will explore the insights behind stakeholder behavior and why people don’t actually read documents. Even if you’ve never worked with marketing concepts before, everything will be easy to follow: complex ideas will be explained through simple, everyday examples — including one pleasant evening drink and music.

Then we’ll see how this perspective can be applied in practice. I will share several documentation design techniques. In fact, after implementing them, I once heard a rather tough team lead say: “Hey, your docs are actually really good!”

I’m confident that after this talk you’ll start hearing that long-awaited phrase more often: “Oh, I get it now!”

GG/GGWP, achievement, skill — gaming slang that has firmly entered everyday language. This talk is, in its own way, also about GG — about the “well-played game”, about the use of gamification in the public sector and the creation of an expert community. 

Game campaigns are actively used in the market by companies such as Yandex, Ozon, and VTB Bank. Therefore, it is not surprising that our key customer also relied on the “game mechanics” to engage their users in creating the necessary value. For some, the value is purchasing goods; for others, increasing customer loyalty; and for the domain I work in, the value is hypotheses of process analytics, suggestions for improving processes (process mining) and ideas for increasing operational efficiency (task mining).

In this talk, I will describe how, starting with user training programmes, using badges and leaderboards, an expert community emerged, and subsequently Competence Centres in process analytics.

In the era of artificial intelligence, turning an idea into a working system has become faster than ever. Code can be generated, prototypes built in days, and technical feasibility is rarely the main challenge. As implementation accelerates, a key question emerges: if almost anything can be built, what guides us in deciding what should be built and how it should be built?

This talk argues that non-functional requirements (NFRs) play a central role in solution design. Usability, accessibility, ethics, and sustainability are design qualities that shape system behavior, user experience, and long-term impact. When addressed late or left implicit, solutions may succeed technically while failing socially or ethically.

The session presents a value-driven approach to NFRs, showing how analysts translate human values into design intentions that influence architecture and interactions. Participants will learn techniques to integrate human-centered NFRs, positioning analysts as solution designers.

In this talk, I will discuss how a team lead can establish a structured onboarding process for analysts in a specific field. I will demonstrate a practical approach that helps reduces the time it takes for a new analyst to become productive and lowers the risks associated with hiring for enterprise projects.

The talk will cover:

• challenges of traditional onboarding;
• the “4 Analyst's Cards” framework;
• monitoring onboarding progress;
• criteria for analyst readiness;
• impact on the team and the business.

The talk includes practice-oriented cases from enterprise and integration projects involving numerous systems and participants.

AI delivers impressive results in code generation, mathematics, and writing. But when you try to apply it in projects where reliable, up-to-date data is required to solve a problem, its effectiveness drops dramatically. And most real business tasks are exactly like this: inventory management, risk analysis, business process optimisation, and dozens of others.

One way to solve this problem is to use MCP, a technology that allows AI models to be supplied with the data they need.

In this talk, you will learn how this technology works, how to implement MCP servers with minimal effort, and how to make AI a reliable assistant for solving business problems.

In 2025, the expert team at SSP Soft conducted over 400 interviews with systems and business analysts, each time assessing candidates' knowledge across 15 key topics: from requirements identification and process modelling to architectural patterns, API integrations, and data analysis.

In this talk, we'll explore: 

• Actual competency gaps.
• Profiles of specialists by level: how the knowledge of Middle, Middle+, and Senior positions differs in practice.
• “Interview bluffing” — how often candidates attempt to present wishful thinking as real experience.
• Market requirements in 2025 and a forecast for 2026. 
• Potential industry trends.
  

Many errors in analysis do not start with wrong conclusions, but much earlier: at the moment when a task is still underspecified, a decision is not yet formalised, yet the text already looks “clear enough.”

This later leads to extra clarifications, repeated discussions of already resolved matters, documents with drifting meaning, and wasted effort — both for people and for LLMs.

In this talk, we will examine FPF as a practical framework for such cases:

• how to unpack tasks and assignments;
  
• how to capture and record decisions;
  
• how to check texts for semantic and ontological accuracy;
  
• how to apply the same techniques when working with non-human assistants.
  

This is not a general overview of AI and not a discussion on good writing style. It is a talk about making working texts and decisions more accurate in situations where an error in wording quickly turns into an error in real work.

How to distinguish the moment when AI amplifies your thinking from the moment when it starts replacing it? In practice, only through experience. During the workshop, participants will get a complex task in which the data contradicts each other, traditional analysis does not work, and “asking AI for the correct answer” is impossible — because the right answer doesn't exist until action is taken. This is the realm of complex problems, and it is precisely here that the difference between an exoskeleton and a wheelchair becomes critical.

Within 90 minutes, the groups will go through three professional Skills, each paired with an AI.

You do everything. Always online. 120% loaded. You’re involved in every sprint, every meeting, every architectural discussion. It seems like you never stop for a second. But in the end — you’re called a low performer.

Why does this happen?
Because busyness masks the lack of measurable impact.
Because autopilot kills awareness, and cognitive biases make you believe that “the more tasks I complete — the more valuable I am.”

This talk is not about burnout. It is about the internal mental traps that turn a strong systems analyst into someone who’s “constantly busy, but useless.”
We’ll explore how cognitive biases create autopilot mode, learn how to recognise it in yourself, and shift from “I do everything” to “I do what matters” — and finally stop fearing being laid off.

The IQSA Report is a system of metrics for evaluating the work quality of systems analysts, implemented within your company. It visualises growth areas, competencies, and overall effectiveness of each specialist through a personalised dashboard.

The Evaluation Problem

Traditional methods for assessing analysts are often subjective and fail to provide a complete picture. Without systematic data, it is difficult to identify strengths and weaknesses, which slows down team development.

The Key Solution
Several years ago, a “Change History” section was introduced into all artefacts. This enabled the collection of data on all edits made by a systems analyst, categorising them by competencies related to the technologies used. 

Results and Value
Each analyst can see their own growth areas and track progress. The system increases transparency, motivates self-development, and helps optimise team performance.

The talk will cover the technical implementation, the metrics used, and key lessons learned.

The cliché quote, “God forbid you live in an era of changes” (attributed to Confucius), is often cited in presentations advocating for stability or stress survival. In stark contrast, China has spent nearly 50 years embracing intensive changes, viewing it as an opportunity for rapid development and prosperity.

I confirmed this during a recent visit to leading Chinese tech companies: Baidu, Xiaomi, Little Red Book, SenseTime, and others. I will present the specific features of Chinese corporate culture and organisation that support this unprecedented growth. As a result, China is now poised to seize technological and political leadership from the US within the next 3–7 years during the industrial revolution. 

This forward-looking mindset can be adapted for our own benefit, and understanding the culture of the world's next leader is useful for scenario planning, as it will inevitably impact the entire world.

Recently, our analysts team has developed and implemented a code-style for working with UML sequence diagrams. But what led us to this decision, and what results have we achieved?

In this talk, I will cover:

• why we created a code style for our UML diagrams;
• the issues we faced while refining it;
• how our team learned and introduced Git into analysts’ day-to-day work;
• what advantages we gained by implementing the code-style;
• how our idea inspired other departments to follow our way.

We change business logic, content, and page structure — without code and unnecessary releases. I’ll tell the story of how we started using BDUI to accelerate development, launch features faster, and shorten the path from idea to production.

This is a story that spans from exploring the existing implementation to burying our own solution, illustrated through the example of the Tele2 Tickets product.

In the world of automotive development, functionality is just the tip of the iceberg. True reliability, safety, and user trust are built on non-functional requirements: response time, fault tolerance, data security, and predictable behavior under extreme conditions. 

In this talk, I’ll share how our team develops an automotive security gateway - where a 10 ms delay can lead to a critical situation, and a message processing failure can compromise the entire CAN network. 

You’ll learn how we identify, specify, and verify non-functional requirements, integrate them into analysis and development workflows, and how they help us meet safety expectations defined by industry standards such as ISO 26262.

This is not a report. This is a public interrogation of the profession.

Two analysts enter the stage. One is a pragmatist who honestly admits that he uses triggers, half-truths, and the "illusion of choice" to push architecture through resistance. The second is his opponent, who knows the mechanics of these techniques from the inside, because she has to resist them every day — and does not always win.

In 40 minutes, they will analyze three topics that are considered to be silent in the profession.

You'll learn techniques that you're already using, but you just haven't called them by their proper names yet. Body and voice as API influences. Why does one image read as "status" and a similar one as "trying to appear status"? You are not lying — you are the curator of reality. You choose the right truth from the available ones.

There will be no finale with answers. There will be a choice, the one that you already make at every rally.

In 2021, Russian Post transitioned to a new system for processing all international mail.

This is a story about the challenges faced by the implementation team and how they managed to keep international mail processing running without a single day of slowdown.

You’re sent an “architectural diagram”. You look at this layered cake of rectangles, clouds, and rainbow-coloured arrows. Something tightens inside: “I’m supposed to understand this. I’m supposed to ask a smart question.”

You nod. You say, “Looks clear overall.” And then come the cries of “That’s not what we agreed on!” —  because the diagram never answered the real questions: what breaks first, who is responsible for it, and how do we test it?

This workshop is about learning to interrogate a diagram like a lying stakeholder.

I'll give you a concrete 5-minute checklist to see if it's worth the paper it's drawn on.

You'll learn how to:

• Find missing entities and ghost arrows.

• Ask three questions that stump the architect (and that's good—you've found a weak spot).

• Tell the difference between a diagram for presentation (a pretty picture) and a diagram for work (a survival manual).

Outcome: You'll get an interrogation algorithm, not just theory. You'll stop nodding. You'll start understanding.

“A fairy tale is a lie, yet it hints at a lesson for the wise.” We've all heard this phrase since childhood. It's believed that fairy tales hold the answer to any question. How often do we find that real-life situations resemble fairy-tale plots, and the people around us — villains, princesses, and other fairy tale characters? But what if we look at an IT project as a hero’s journey and map its stages to the events commonly found in fairy tales?

This talk draws on Morphology of the Folktale by V. Propp, suggesting that all fairy tales follow a structured set of functions performed by characters — much like projects follow defined stages and roles. This theory is used in cinema and politics, and we will apply it to the real-life work of a business analyst. We will examine the parallels between The Frog Princess and dashboard development, and uncover practical benefits of this model to improve communications with the client and reduce the chaos of requirements, based on a real-life case.

We experienced a painful failure — the system couldn't handle real load and crashed in production. This incident forced us to rethink our development approach. Today, our analysts independently conduct load testing during the discovery phase.

What you'll learn: 

1. Why it matters: why load testing is not a task for DevOps or testers “afterward”, but the responsibility of an analyst “beforehand”. 

2. How the process changed: how to integrate load testing into the discovery and requirements elaboration phases. 

3. Tools: what simple and accessible tools analysts use for testing. 

4. The outcome: how this practice prevents architectural mistakes at early stage and saves from production failures.

When incidents are handled by heroes and documentation becomes outdated before release — it's a process problem, not a people problem. How can an analyst become an architect of a healthy engineering culture and make reliability systemic?

In this talk, I will share two key levers based on personal experience.

Service Level Agreement as a process contract. How I introduced the first measurable contract in the “Ilon” service. You will see the full journey: from identifying critical scenarios to aligning metrics with the business. The result — the team moved from firefighting to managing an “error budget.”

Documentation as Code as a law of the ecosystem. How I promote the “documentation as code” principle. Saving 600+ hours per year and making relevance the standard, not a feat. Automation reduces risks by tens of millions of rubles.

Outcome: a practical toolkit for designing reliable processes. You'll take away templates and a plan for your first actions.

Stress during requirements defence or difficult negotiations immediately affects the body: breathing becomes irregular, the voice trembles, and complex terminology turns into a mess.

This workshop provides IT professionals with a clear 5-minute algorithm to reduce anxiety and prepare for any presentation.

Training programme:

• Before/After Demo: a clear demonstration of how the voice sounds when reading complex texts without preparation and after a short vocal warm-up.

• Quick Tune-Up: releasing physical tension, practising “box breathing”, and activating a deeper, confident chest voice.

• Articulation: a quick warm-up for clearly pronouncing complex IT terminology without stumbling.

• Dialogue Management: practising the “toxic stakeholder” scenario—learning how to regain initiative through pauses and slowing the pace, rather than trying to speak louder than the opponent.

Key Message: An analyst does not sell documents but meaning. And meaning is conveyed best through a calm and well-prepared voice.

In a classic development process, an analyst defines requirements, but even the most polished specification does not protect against bugs and misinterpretation. Text can be interpreted in different ways, and feedback arrives too late — together with the implemented feature. This leads to painful rework and missed deadlines.

But what if an analyst could deliver to the development team not only requirements, but also formal, executable criteria of their correctness — ready-to-use autotests?

In this talk, I will show how our team introduced this practice and what results it brought. I'll cover what a tool set we use to work with tests. During the talk, you will develop an autotest for a typical scenario using a ready-made algorithm, which you will be able to apply in your own projects.

NULL in SQL is not just a technical feature – it's a full-fledged database saboteur. It disguises itself as a harmless “absence of a value”, but in reality creates logical paradoxes that break business logic. Different DBMSs handle it in their own ways: sometimes it's unique, sometimes equal to an empty string, and sometimes it is not even equal to itself. As a result, queries start lying, reports show fake analytics, and money quietly leaks through data holes. The most expensive and hilarious incidents in IT history are often tied to NULL: products become free, users turn immortal, and secret agents get suddenly exposed. This talk is a collection of real nightmares that happen when NULL gets out of control. We'll explore why three-valued logic breaks conventional thinking, how to avoid financial losses, and what to do to ensure your code doesn't become the next funny story. Get ready to laugh at others' mistakes – so you don't repeat your own.

Import substitution of complex enterprise products is often considered a task of “replicating functionality”. In practice, this is an illusion. 

In this talk, I will share real-world experience of full product replacement in the MarTech domain — from initial business expectations to a production-ready in-house product. The talk focuses on product development decisions, necessary compromises, and lessons learned, for which the team paid with time and money. Special attention is given to the key product and domain challenges, their impact on delivery, and the decisions that made it possible to evolve the solution from an idea into a stable product in production. 

The talk will be useful for product managers, as well as systems and business analysts involved in product development, import substitution, and complex domain-driven products, where the cost of architectural and analytical decisions is especially high.

API documentation is the primary means of communication between an API provider and the developers who will integrate with it. That is why API documentation must be first-class.

In this talk, I will cover the key questions that API documentation should answer, the essential components of a high-quality developer portal, and the kind of user experience it should provide—along with other practical insights to help your API product stand out from the competition.

An honest story about how an attempt to get rid of “excess” documentation when developing with AI led to an unexpected discovery: analytics artefacts are needed even more than before, just in a new format.

Analysts are excellent at working with requirements, managing customer expectations, and even have some experience with value and metrics, but they often remain unaware of the core business question: does a product make money?

Our workshop will confront analysts with the harsh reality: a product can be “beautiful and useful” but still be unprofitable. 

Participants will have to step out of the “requirements swamp” and try to tame a scary beast—the product's unit economics.
They will have to learn to think in terms of money, acquisition channels, and market capacity constraints. Evaluate product potential and choose a promotion channel and monetisation model for it.

After all, the issue of ROI in IT is becoming increasingly pressing and urgent. Those who can calculate these economics will have greater opportunities in their careers and in the job market.

The talk is devoted to a methodology for rapid immersion of an analyst into an IT project to achieve maximum work efficiency. 

Special attention is given to tools and techniques for accelerating the integration process of a new employee into the workflow, such as creating a detailed onboarding plan, regular training and mentoring, as well as using specialised international practices for project immersion. 

The practical aspect of the talk includes recommendations on applying methods depending on the type of project (light, medium complexity, complex, and very complex) through optimising internal team communications, risk management, and improving the quality of the final product by effectively distributing roles and responsibilities of the analyst.

In a large company with large amounts of data, tasks that are difficult and expensive to scale manually occurs regularly. At the same time, these tasks are standardised, repetitive, and well-suited to formalisation, making them strong candidates for automation.

This talk describes practical experience and results of implementing large language models (LLM) and simple agent-based logic to automate:

• creating data quality checks, 
• searching and classifying personal data,
• managing access grants,
• preparing secure data for development.
  

Should an analyst consider and anticipate risks, or is risk management solely the responsibility of managers?

In this talk, I'll try to dispel common myths about risks and show how potential problems can be turned into a driving force for our achievements. And this is not just theory from books, but also my own experience in IT and beyond. If it worked for me, it can work for you too!

When choosing a direction for further development among the many competencies useful for an analyst, it is worth focusing on thinking skills, as they remain relevant in any context.

In this talk, we will explore one of the approaches to structured seeking solutions of contradictions using standard techniques from TRIZ.

Using a practical example, I will demonstrate how methods from a different domain can be adapted to solve an IT-related task.

Today, the IT industry is dominated by the idea of rapid job rotation: if a project gets difficult — leave. I followed this myself, changing companies every 1-2 years as a programmer and project manager. However, working on a long-term project changed my perspective.

In this talk, I'll share my experience as a system analyst on a bank's document generation product. We evolved from 4 people to two teams (10 each), building complex business logic, integrations, and proprietary client platforms. I grew from junior to middle+, experienced multiple burnouts, took on excessive responsibility, and rethought my role.

This isn't about “enduring at any cost.” It's about why you sometimes shouldn't leave at first difficulty, how to tell a dead-end from a growth point, and what truly maintains motivation.

This talk is for analysts who are unsure whether to stay or to look for something new.

In large IT teams, analysts, developers, and support engineers spend a significant amount of time every day searching for information scattered across documentation, contracts, technical descriptions, and requirements spread over multiple GitLab repositories.

In this talk, I will introduce DocsGuru — an AI agent integrated into Mattermost that answers user questions based on corporate documentation, leveraging a RAG approach and semantic search.

We will break down the solution’s architecture and see how such a bot reduces the workload on analysts and accelerates team performance.

The talk is aimed at systems analysts and architects who want to understand how to apply AI not in abstract terms, but to solve a concrete task — working with corporate documentation.

Many of us use the C4 model diagrams and their abstractions, considering them intuitive and easy to use.

But are you sure you are using them exactly as the author of the model — Simon Brown — originally intended?

In this talk, I will cover:

• what the author actually means by the C4 model;

• where analysts most often make mistakes when using the model;

• how the author recommends representing certain elements of the diagrams;

• which diagrams exist in C4 beyond the familiar four levels;

• how Simon Brown recommends styling and presenting diagrams;

• some interesting questions people ask Simon about the model, and how he answers them.

The talk is entirely based on Simon Brown’s books and public presentations.

This talk explores the introduction of agile methodologies and the transition to corporate documentation standards during the delivery of the largest development project in the team’s history.

You have an idea for how to improve, propose a change, or have come up with a promising change for yourself. Everything seems fine. But along with this interest, there may be fear and aversion, a reluctance to try something new. Is this bad? No, it's normal: the part of the brain that generates pleasure from the familiar and stable has been activated. But is there any other way to persuade someone?

Within the workshop, we'll look at change from the perspective of the balance of pleasure in the present and future. It exists in both. To do this, we'll examine the Change Brain Energy Scorecard model and create a 7-component structure that helps you formulate your idea and proposal so that the brain activates the pleasure system for the future and encourages change and new experiences.

This workshop is for those who are developing and changing themselves, helping others change, and seeking a tool to make the process clear and far less intimidating.

Modern LLM systems and agent-based solutions demonstrate that the quality and predictability of their behaviour are determined not so much by the model itself as by the context in which it operates. Using prompts without preparing and analysing the required context leads to unstable results, hallucinations, and difficulties with scaling.

This talk examines what kind of context is required for effective use of LLMs, the extent and format of that context, and why “more context” does not mean “better”.

We'll analyse the key context levels, tagging features, and the use of existing artefacts. We'll also explore techniques for working with context and discuss the role of the systems analyst in preparing context and creating effective agents.

The analysis of user behaviour in large digital products often comes up against the problems of working with raw data with a complex structure, the lack of a unified attribution scheme for actions, and the fragmentation of expertise. This leads to low efficiency of analysts, the risk of making wrong decisions based on disparate metrics, and missed cross-functional opportunities.
In this talk, we will present an approach to solving these problems by building a centralised user action mart. We will explain how we standardised the collection, attribution, and representation of user actions (views, clicks, add-to-cart events) linking them to the business context. You will learn how this approach has simplified the data, unified the methodology for calculating key metrics for A/B tests and dashboards, and freed up many hours of analysts' work.
The talk will be useful for system and business analysts and for all analysts, heads of analytical departments, data architects and product managers.

In a world where code is written “by vibe”, context is the only scarce resource. And the analyst is the one responsible for it.

Code has become inexpensive. LLMs generate services, APIs, and schemas faster than a team can align on terminology. Development increasingly happens “by vibe” — and at that moment, requirements stop protecting us from mistakes.

Projects fail not because of the code and not because of user stories. They fail because of incorrect context: blurred boundaries, mixed domains, inconsistent language, and unexamined assumptions. And this is the analyst’s direct area of responsibility.

In this talk, we will discuss vibe analytics — the ability to work with uncertainty, maintain a coherent domain model, and stop attractive but risky solutions proposed by AI. We will show why the analyst no longer “collects requirements”, but designs context: the boundaries, language, and assumptions within which a team can make decisions.

Code can be rewritten. A mistake in context cannot.

Why do business processes break down at the junction of ERP and Digital systems? Because the traditional analyst roles have reached their limit. We introduce the new key role of the Integration Analyst and demonstrate, based on real experience, how this role becomes the architect of end-to-end processes, overcoming the chaos of system disparity.

You will learn who can grow into such a specialist, what three key artefacts they wield, and how their work brings predictability and speed to the business.

This talk is a ready-made transformation case study and a roadmap for implementation.

How often have you seen process diagrams that look more like a maze than an instruction? Confusing flows, notation-overloaded charts, lack of logic — all of this turns BPMN from a powerful tool into “an art for the chosen few”. But that's not how it should be!

In the workshop, we will conduct a practical review of the BPMN modelling basics — without the fluff, complex theories, or professional jargon.

I'll explain:

• simple rules that make your diagrams readable;

• typical mistakes — and how to avoid them;

• features that speed up your work: how to simplify complex processes without losing meaning.

This workshop will be useful for anyone who works with processes. Even if you have never created a BPMN diagram before, after this talk you will be able not only to “read” them, but also to build clear and workable models yourself.

Studying processes is like learning a language. Let us begin with the alphabet — and then even the most complex diagram will become a story rather than a puzzle.

If, as an analyst, you are involved in interface design but are held back by the fear “I can’t draw” and don’t know how to make things better — this talk is for you. I’ll show that design is not about artistic talent — it’s about systems thinking.

You’ll learn about five practical steps that help you master design tools, manage user attention, create logical and clear interfaces— without having to become a designer. These principles will be useful not only for analysts, but for anyone who works with interfaces, presentations, or even documents.

Trust in digital systems cannot be added at the end—it must be built into the foundation from the very beginning.

In this talk, I’ll show how the systems analyst becomes the key figure in shaping ethical architecture: defining not only what a system can do, but also what it should or must not do.

Drawing on international standards (including IEEE 7000), regulatory requirements, and practical engineering practices, you’ll learn how to turn ethics from an abstract principle into verifiable requirements—from BRDs to user stories—and lay the groundwork for systems that truly deserve users’ trust.

This talk is dedicated to analyzing a complex professional profile that does not fit into conventional career schemes and resists being read through a template. We consider such a trajectory as an analytical task: to gather disparate elements, identify the connections between them, and understand where external chaos ends and internal logic begins. 

The focus is on hybrid experiences, which at first glance may seem too diverse but, upon closer examination, form a coherent and meaningful professional picture. 

The talk demonstrates why standard models often oversimplify or distort non-traditional paths and why a more accurate, multilayered analysis is needed in such cases. 

Ultimately, it is not just about how to read an analyst's profile, but rather about how to see the structure behind the fragments, the system behind the diversity, and the real value of experience behind complexity.

This talk explores the “business architecture as code” approach using the Dochub tool, illustrated through an e-commerce example.

Are you ready to take an SQL quiz? Let’s see how well you know the subtle, non-obvious, and sometimes amusing quirks of the language. Join in to learn something new in a playful format! And most importantly, remember: write your SQL in a way that it can’t be reused for future quizzes.

It’s easy to hide almost anything in requirements: auto-subscriptions, pop-up banners, a “great” metric that masks an uncomfortable truth. And typically, it doesn’t look like malicious intent, but like necessity. At what point does it become an ethical issue rather than a product trade-off, and where is an analyst’s personal boundary?

We’ll look at real practice: how to spot the grey zone early in wording, user flows, and reporting; how to turn a vague sense that “something feels off” into clear questions and arguments; and how to define boundaries in a way you can defend them in discussions with decision-makers. No moralising — just tools that help you make conscious choices without losing self-respect.

In a new product, an analyst rarely remains a “requirements writer.” When working with large-scale functionality, the analyst inevitably contributes to the development of product logic: scenarios, constraints, and trade-offs.

In this talk, I'll discuss how the role of a business analyst changes when they become a co-creator of product solutions, using the example of a real project design as a key feature of a new direction. We'll explore areas of responsibility, points of influence, and the boundaries where an analyst truly shapes the product rather than simply describing it.

• what legal minimum is required for an analyst: key concepts in the field of PD, core provisions of Federal Laws;
• how to extract specific requirements from regulatory sources;
• how to transform legal norms into functional and non-functional requirements, as well as acceptance criteria;
  
• which typical mistakes lead to violations and fines;
  
• why it is necessary to handle a register of operations;
  
• what the difference is between logging and journalisation of personal data.
  

Participants will get:

• a checklist for identifying PD within a system;

• a ready-made use case, “Recording a PD Operation in the PD Register”;

• structured functional and non-functional requirements, along with acceptance criteria.

In companies, system analysis often evolves in an ad hoc way: requirements are described in different ways, processes are not documented, analysts’ responsibilities are blurred, and stakeholder expectations are often contradictory. As a result, it can be very difficult for a new Head of Department or team lead to understand the current situation. 

In this talk, I will examine the audit of systems analysis as a practical management tool. I will provide a step-by-step approach: what to check and in what order, how to select stakeholders, what questions to ask them, and how to document the results. 

Target audience: Business and systems analysts — seniors and team leads. 

What the participants will take away: 

• an understanding of why and when an audit of systems analysis is needed; 
• a clear structure for external and internal audits; 
• a set of practical steps and templates for conducting an audit; 
• an understanding of how to turn the audit results into a plan for change.
  

The report is dedicated to the architecture and principles of building NRT reporting (Near-Real-Time) — a system for processing data in near-real-time mode. The report discusses its key advantages, features, architectural solutions, and software used. 

The goal of NRT reporting is to promptly provide up-to-date data for making management decisions, quickly identifying risks, and automating business processes. 

The report will be useful for IT specialists, data analysts, and managers involved in the design, development, and maintenance of operational reporting systems.

I will also share our company’s experience, highlighting what to consider when choosing an external provider and what to plan for when integrating it.

The workshop explores the key components of emotional quotient (EQ) for analysts, such as empathy, self-awareness, and motivation, and their role in professional practice. Special attention is given to applying empathy and motivation for effective communication with clients: identifying hidden motives, practising active listening, and building trust. It also uncovers principles of using EQ when working with development teams to understand their motivations, resolving conflicts, and improving team dynamics. Finally, practical tools for developing emotional quotient are presented, including exercises, checklists, and success metrics that help enhance interaction quality and speed up requirements' alignment.

Analysts rarely get their conclusions wrong. Much more often, they get the timing, tone scale of the conversation wrong. The problem is that senior executives operate with other lenses: they want to “deal with it” quickly and move on. And you have 10 min. instead of 40 — not surprised the meeting ran over, are you?

We'll discuss how to speak, listen, and ask questions to get clear answers without distortion and irritation. Why clarity is valued more than depth, and predictability more than a perfect outcome. What “reliable people” look like from the executives' perspective — and why they're the ones executives keep coming back to.

We'll also cover habits that quietly increase your weight in the system: when you start being considered in advance, brought in without formal triggers, and given time because you asked. After this talk, you may not be praised more. You’ll simply start being taken further and higher.

P.S. At the very least, it will become easier for you to fit in there and grow.

With the adoption of DBT, Git, and CI/CD, analytics stops being just a data request — it becomes a data product that must be documented, testable, repeatable, and stable.
The role of a systems analyst is evolving beyond SQL. Now, the analyst is becoming the owner of data platform components, participating in development, testing, code review, and SLA management.
In this talk, I will share how Git and CI/CD workflows are transforming the analyst’s role, improving data quality and reducing time-to-market for analytical solutions in production.
The talk will include real-world examples from practice, such as:

• how analysts create and manage Git branches,
• how business logic tests are integrated into CI/CD pipelines,
• and how SLA and documentation are becoming part of the development process.

Caching may seem like a purely technical topic, but in reality it’s often the analyst who must foresee where data can become outdated and how that will affect users.

In this talk, I’ll explain:

• the different types of caches;

• how they differ from one another;

• where their use tends to “explode” in production, and how to account for caching properly in requirements.

Why this matters for analysts:

Caching-related mistakes lead to bugs that can’t be “fixed with a button” — and users blame the entire system, not the cache layer.

An analyst can prevent such situations long before development even starts.

• how to interpret the answer to the question correctly; 
• which markers speak in favor of the candidate and which ones are against; 
• how to steer an interview conversation in the right direction; 
• what practical cases are worth giving.

  
  

We spend a huge amount of time not on designing, but on “knowledge archaeology” — searching for relevant requirements and answers to colleagues' questions. Attempts to introduce AI often fail because of data quality: neural networks hallucinate without understanding our tables, schemas, and specific specification formats.

How can we turn scattered documentation into a smart assistant that answers questions about business processes and integrations?

The talk is devoted to the technical implementation of RAG (Retrieval-Augmented Generation) using modern tools. We will explore why proper parsing (LlamaParse) is crucial for complex specifications with tables, how to organise knowledge storage in a vector database (Pinecone), and link it all into a single process without deep programming using n8n.

The talk will include real-world experience, architectural schemes, and error analysis during data preparation.

One way or another, all analysts come across BPMN in the context of optimisation and automation. The problem is that BPMN does not help with optimisation, while automation is the most expensive and time-consuming way to improve a process.

In this talk, I will cover 59 more ways to optimise processes and explain in detail the mathematical foundation behind real improvements.