Professional background — key abstracts
Professional background spans computational physics, software engineering, quality assurance, infrastructure and systems integration, telecom BSS delivery, data migration, consulting, business analysis, solution architecture, and customer-facing technical presales.
Experience includes direct employment, external consulting, subcontracted delivery teams, and customer-side assignments. Legal employer, staffing intermediary, implementing vendor, and end customer are distinct relationships and should be recorded separately.
Several programs were postponed or stopped because of customer procurement decisions, the COVID-19 pandemic, geopolitical restrictions, or other program-level circumstances. Completed individual assignments, successful technical proofs of concept, and shortlisted proposals must not be described as completed programs or signed sales.
Core professional strength is the ability to connect hands-on engineering and software development with business analysis, architecture, executive communication, presales, and cross-cultural teamwork.
Education and the technical foundation
Moscow Institute of Physics and Technology — 2002 and 2004
I studied at the Moscow Institute of Physics and Technology (MIPT) and received two diplomas in Applied Mathematics and Physics: a bachelor's degree in 2002 and a master's degree in 2004. Both were related to computational physics. My university background was not mainly about using ready-made software products. It was about understanding a physical problem, transforming it into a mathematical model, selecting numerical or analytical methods, and implementing computations.
For my bachelor's thesis I studied possibilities for parallelizing numerical calculations associated with Newton-based methods for solving differential equations. My master's thesis concerned symbolic representation and solution of chemical-reaction systems, using the rates of elementary reactions that make up more complicated combustion and oxidation processes. These subjects required mathematics, physical modeling, programming, and the ability to research unfamiliar methods independently.
Before my first full-time IT position, I had already used C++ and FORTRAN for scientific calculations, knew MySQL, and could write simple PHP scripts. But this knowledge was still fragmented. I understood different technical pieces without yet having the systematic view of how real commercial software products are designed, tested, delivered, and operated.
Postgraduate research in plasma physics — September 2004 to September 2007
I also undertook postgraduate research at the Troitsk Institute for Innovation and Fusion Research in computational physics and low-temperature plasma physics. My work was supervised in the Laboratory of Plasma Physics, under Igor Valeryanovich Kochetov. This was a postgraduate research period, not a defended PhD and not an awarded doctoral degree. The officially available period for this research was September 2004–September 2007.
The practical research problem was to model three-dimensional corona discharge near a sharply curved electrode, for example a needle or lightning-rod tip. The difficulty was not merely solving a standard equation. The geometry created very different scales of variation in the same model. The mesh cells in one part of the computational domain might need to be roughly one hundred times smaller than elsewhere. I had to investigate stable numerical methods suitable for such geometry and study how other researchers prepared three-dimensional calculation meshes, including methods for adapting the mesh to local electric and magnetic fields or gas-density variations.
This period strengthened my approach to unfamiliar technical problems: study the underlying principles, compare available techniques, test their limits, and do not assume that a method is suitable simply because it works in an easy example. Although I later moved far from scientific computing, this style of problem-solving stayed with me.
SWsoft — software QA, virtualization and hosting products
My first professional IT job started during the summer vacation after my fifth year at university. I applied for a junior QA engineer position at SWsoft, a software company associated with Sergey Belousov, who had also studied at MIPT. The office was conveniently located on the university campus. I began as a junior specialist and developed toward a stronger, more automation-oriented QA profile.
SWsoft was working in areas that were particularly relevant in the early 2000s, after the growth of commercial web hosting. Its products included Virtuozzo, an early commercial solution for operating-system-level virtualization and isolated containers, and hosting-management products such as HSPcomplete and Plesk. HSPcomplete covered many aspects of a hosting provider's business: customer-facing management, billing, service provisioning, lifecycle operations, website configuration, domain registration, DNS, and installation or configuration of hosting-related software. I worked with products for both Linux and, in later releases, Windows environments.
This was valuable for my technical development because I was not testing just one simple application. I learned how Linux works at a relatively low level, including aspects of the operating-system kernel, processes, filesystem behavior, service configuration, and the interaction between infrastructure and business applications. I also learned why these technologies mattered commercially: how a hosting provider could use virtualization and automation to manage many isolated customer environments and reduce manual work.
My duties included preparing detailed test scenarios, manual testing in the Linux shell, GUI testing, functional and regression testing, and installation and upgrade testing. I used different Linux shells, particularly Bash, and began using Java for GUI test automation. One useful part of the work was writing reasonably complete test-scenario documentation, sometimes quite large, so that knowledge could be shared within the team and regression testing became less dependent on individual engineers. The objective was better coverage, earlier defect detection, and readiness for product releases.
This was the period when fragmented university-level technical knowledge became practical engineering experience. I was not planning to spend my whole career as a test engineer, but I am glad I started there. It gave me a broad view of development and quality processes, virtualization, Linux and Windows systems, web infrastructure, databases, and the business purposes of software. It also made it possible for me to join a major telecom vendor in my next job, even though I had no telecom BSS delivery background at that point.
For company-name consistency, SWsoft / now Parallels is a useful way to identify this part of my career. The historical naming of the company and its related product businesses changed over time, and not every corporate or product transition should be treated as a simple legal rename.
Alcatel / Alcatel-Lucent — telecom BSS and Contact Center delivery
This was one employment period with two different customer projects, rather than two separate employers. I started with the billing transformation at BeST in Belarus and later moved into Genesys Contact Center activities, particularly for MTS Russia. While the second project was beginning, I still participated remotely in scheduled support for the first project. The projects therefore should not be imagined as two completely disconnected blocks.
BeST, later life:) / Life, Belarus — my first major BSS delivery project
When I joined Alcatel I already had a solid general IT background, but I knew almost nothing about telecom billing. I was sent to Belarus to help deliver a new BSS for the mobile operator then known as BeST, which was later rebranded as life:) and Life. This assignment became the real beginning of my career in telecom projects. It was the first time I could observe a large system delivery from testing and migration through launch, operational support, and changes to how a telecom operator served its customers.
The vendor and product relationship was quite interesting. Alcatel was primarily a major telecom equipment vendor and had its own traditional intelligent-network platform for prepaid services, but for the broader billing solution it worked with LHS, a German BSS software vendor. We were delivering LHS products as part of an Alcatel project. During the project, Ericsson acquired LHS, which complicated the strategic relationship between Alcatel and its BSS partner. Nevertheless, our Alcatel team received approval to finish the work.
The project had two major migration phases. The first phase was the migration of postpaid subscribers, predominantly business customers, using CDR-based offline charging. This phase went live in November 2006. Because I had been a QA engineer before joining Alcatel, I was initially most involved in testing and acceptance activities, including direct work with the customer. I was a major hands-on participant in these activities, but I was not the person formally accountable for the acceptance result of the entire project.
After the first migration I became involved in troubleshooting, support and operating activities. These included supporting monthly billing and invoicing, investigating incidents, analyzing logs, optimizing reporting or logging, and participating in 24-hour support shifts around critical events. As often happens in integration projects, the boundary between testing, troubleshooting and operational support was not rigid. I gained practical familiarity with billing, rating and charging, mediation, online charging, invoicing, customer-care-related operations, provisioning, reporting and accounts receivable. This does not mean that I personally designed or configured every one of those domains: in many cases I provided support and investigation rather than production configuration ownership.
The second phase was technically more unusual. The operator's remaining prepaid subscribers were served by a traditional Alcatel IN black-box platform. Our team worked to migrate them to LHS SDPx, a software-based online charging solution that could run on standard commercial server hardware and Unix-based operating systems. In spring 2008 the prepaid phase was migrated. As I understood it at the time, our delivery team had completed one of the early successful projects of this kind in telecom, and it was the first successful implementation of this migration approach for LHS SDPx. The significance was the move away from a specialized closed platform toward an installable and maintainable software solution.
There were many practical challenges and demanding periods of on-site work and stabilization after the launches. The postpaid launch was followed by intensive support in late 2006, and the prepaid launch by similar activity in spring and summer 2008. Further product customizations followed in 2008 and 2009. My main on-site assignment ended around January 2009; in my original pre-cutoff account I described continuing remote support shifts, including on-call incident coverage, until approximately the end of summer 2009, while also beginning work on the next project. The overall delivery work reached a successful conclusion in 2009.
This project changed my view of enterprise software. Before it, I had worked on products and testing; here I saw how a major system affected the commercial operation of an actual company, how many unrelated technical components had to work together, and how much communication with customer engineers was needed after the software was supposedly ready.
Genesys Contact Center and MTS Russia — learning a new domain and building automation
After my main Belarus on-site assignment, I joined activities related to Genesys Contact Center solutions. Genesys was part of the Alcatel-Lucent product landscape at the time. This was another domain in which I initially had little practical experience, so I consciously started with Contact Center test engineering to learn the product and its behavior before trying to take on more complicated tasks.
Early activities included Contact Center testing or deliveries for customers such as Lamoda and DOM.RF, and development or extension of an existing Genesys Contact Center environment for MTS Russia. In MTS-related work there were projects around online chat, improvement of existing IVR functions, and a pilot for video IVR. This was a period when traditional voice-only call centers were evolving toward broader contact centers that handled additional forms of digital communication. I attended formal Genesys training in the United Kingdom, including developer-oriented courses, and gradually became more useful in the product area.
My largest continuing contribution in this period was automation of infrastructure monitoring data collection and reporting for the MTS Contact Center environment. The operator had more than 100 relevant servers distributed across multiple geographic macro-regions. Existing operational monitoring could raise alarms about immediate overloads, but the team needed accumulated historical statistics for trend analysis and capacity planning. There was no conveniently available, unified long-term reporting system for the task we needed to solve.
The problem had several parts. First, I needed to collect CPU, memory, disk I/O, network and other statistics across servers that were not identical in configuration. Second, monitoring scripts had to be rolled out and updated on many distributed systems. Third, archived information had to be periodically collected and consolidated. Finally, the result had to be usable by the people who would actually analyze infrastructure health—not just raw log files or thousands of rows of numbers.
I developed Bash, Java, and Visual Basic for Applications (VBA) components to automate script distribution, data collection, archiving, downloading, processing, and report generation. The Java-based reporting tools produced human-readable documents, including summary tables, graphs and charts, for all macro-regions, selected regions, individual servers, and selected periods. Infrastructure specialists and administrators used these reports to make their own conclusions about system behavior. I built the automation and reporting mechanism; I was not the infrastructure administrator responsible for the health assessment or for operational ownership of the servers.
The result enabled periodic infrastructure reporting that previously would have required considerable manual effort. Alcatel management considered the solution useful enough that it might be reusable or even separately commercialized, although I do not know whether it was ever sold as a product. After producing a second annual reporting cycle, I decided to leave Alcatel and take some time with my family before starting a new assignment.
For this period it would be misleading to describe me as the overall Contact Center architect or the main person responsible for customer operations. More experienced colleagues owned much of the domain expertise and delivery work. My contribution was learning the new area, participating in testing and evolution projects, and independently building a significant automation solution that made the team's work easier.
Rustim / Borlas (IBS Group) — electricity billing development
After telecom BSS work, I joined a project in a different billing industry: electricity retail. My actual employer was a small IT company called Rustim, which provided technical specialists to larger project organizations. In this case I worked on a project delivered through Borlas, associated with IBS Group, for Chelyabenergosbyt, a regional electricity retail company in Russia serving household and industrial customers.
The target product was Oracle Customer Care and Billing (Oracle CC&B). It was useful for me to see that the business ideas behind telecom billing could transfer into utility billing, even though the product and operating rules were different. As it was explained in the project context, the product carried considerable legacy functionality originally associated with COBOL, alongside functionality developed in Java. The coexistence of legacy and modern implementations was an important architectural feature of such an enterprise billing system, not something I personally designed or replaced.
I completed approximately two weeks of on-site project training and then began working on real development tasks. The project was comparatively well organized. Analysts and architects provided clear technical specifications, and communication between business and technical participants was established. I implemented required functionality in Java, wrote complex SQL queries and materialized views, and delivered assigned modules to the agreed deadlines.
This was not a management or architecture position. I worked as a Java and SQL developer, applying my prior billing knowledge while learning utility-sector specifics and gaining additional experience with a large enterprise application's data layer. It was a useful reminder that important business-system concepts are not confined to telecommunications.
Rustim / Step Logic — regional tax database migration in Uzbekistan
In a second assignment through Rustim, I worked as a data migration consultant for Step Logic, the main project contractor for the State Tax Committee of the Republic of Uzbekistan. In the revised chronology this Rustim period is shown as January–December 2012. It overlaps at the end of the year with the next Ericsson engagement in the CV; that overlap should be retained rather than silently forcing one period to end earlier.
This was a government infrastructure modernization project. The tax administration had a highly decentralized legacy computing landscape: approximately 200 regional tax offices, many of them operating applications and databases on small, isolated servers or even ordinary PCs. Software versions and database contents were inconsistent; backup practices and disk redundancy were sometimes inadequate; and in many regions there was no practical remote administrative access. All of this made nationwide software support, database integrity, and disaster recovery difficult.
The modernization program created two more centralized data-center sites, with high availability and geographical disaster-recovery capabilities. Local application developers were responsible for adapting the business software and database structures. My responsibility was narrower and technical: consult developers and DBAs about the migration, install and configure Oracle 11g Release 2 and its database clustering components, propose a feasible high-availability approach, and help make the consolidation process executable and safe.
A particularly difficult issue was the absence of a realistic way to rehearse the whole migration. The legacy offices could not simply send complete datasets across a network; in many cases physical disks would have had to be transported. We could therefore rehearse on only a small subset, including ten databases from offices in Tashkent. That was a very limited sample of the data and inconsistency cases that might appear during the full national migration.
I proposed an incremental region-by-region migration so that production work could continue during daytime hours. The local developers owned the underlying business-data migration logic. I adapted and extended the migration scripts to automate execution and reduce the chance of human mistakes. I added checks for known data inconsistencies, and logging and reporting to make unexpected cases visible rather than letting them disappear silently into a bulk migration.
I also worked with the team on the target database configuration. We initially chose an Oracle RAC active-active approach in the dual-site environment, hoping to use the available hardware efficiently. At the time there were mixed practical reports from experienced Oracle administrators about RAC complexity and stability. I was aware that other infrastructure designs might be possible, including more dynamic use of virtualization, but those were not areas in which I had sufficient hands-on confidence then. The initial RAC implementation did have operational problems over the following months and was eventually changed to an active-standby model. I think it is important to say that explicitly rather than presenting the first architecture decision as flawless.
Together with a local DBA, I carried out the first ten regional database migrations, tested the process, and helped transfer sufficient knowledge for the local DBA to continue the rest of the rollout. My contractual assignment was completed at that point, though I continued to help when questions arose. The wider regional migration took approximately a month and was completed by the local team. I worked closely with customer IT leadership, including the committee's CIO, and sometimes participated in discussions with the senior government-side project owner.
The modernization project succeeded overall, even though specific technical choices required revision. This was my first major government customer assignment. It was especially memorable because a project that may not have appeared extraordinarily advanced technically had a direct, visible effect on an entire country's administrative infrastructure. It also reinforced the importance of data quality, realistic migration rehearsals, fallback planning, and documenting what local teams must be able to do after an external consultant leaves.
Ericsson / A1 Belarus (formerly Velcom) — BSS transformation
This was an external consulting engagement arranged through Networkers, not a claim that Networkers owned the BSS project. I joined the team working for Ericsson on the transformation of Velcom's billing environment in Belarus. The customer is now known as A1 Belarus. This project later became an important part of my professional background because I returned to the same operator in different roles, through Fideware and Seavus.
The project's main purpose was to replace a legacy third-party billing platform with Ericsson BSCS iX. The delivery was unusually complicated because more than 70 changes to core BSS functionality had been agreed during the preceding commercial phase. I had not participated in that sales phase. From a delivery perspective, the number and depth of customizations meant that the team was not simply installing a standard product with a few extensions; some fundamental behavior had been changed or redesigned specifically for this customer.
In modern terminology, the overall system landscape involved charging, billing, invoicing, mediation, order management, CRM and supporting infrastructure, including high-availability arrangements. I developed a working understanding of many of these parts and could take on temporary troubleshooting or consulting tasks across them. However, my principal responsibilities were more specific: Order Management / Credit Control and performance of the customer-customized CRM GUI, together with related testing and problem investigation.
The CRM interface was not Ericsson's standard, stable product GUI; it had been substantially customized for the operator. I was asked to find why it did not perform adequately under realistic concurrent user loads. I independently built a Java and Selenium-based performance-testing tool that could run across approximately 30 virtual machines and emulate around 700 independent parallel GUI sessions. This let us reproduce realistic load and investigate both blocking defects and severe response-time problems.
I then worked iteratively with the CRM development team to identify, correct, and retest critical problems. Some work also took place during demanding migration rehearsals, including rotating 24-hour troubleshooting support. I communicated directly with customer engineers and helped with other issues where my knowledge of the system was useful. By resolving a number of significant GUI performance problems, I contributed to the conditions necessary for the successful migration and production launch.
I would not call myself the overall transformation architect or project manager. I was a senior hands-on consultant and engineer who understood enough of the BSS landscape to be useful beyond one narrow test task. Most importantly, I came away knowing the customer's billing platform, business arrangements, technical personnel and management contacts. This knowledge proved valuable in later projects at the same operator, although those later projects were for different suppliers.
Ericsson / MTS Russia — television service acceptance testing
After the Belarus BSS work, I took another external consulting assignment, again arranged through Networkers, working with Ericsson for MTS Russia. This time the project was not traditional mobile billing. It was a complex television-service delivery program involving IPTV, satellite TV and cable TV, together with OTT services, TV middleware, set-top boxes, user interfaces, and integration with regional billing systems.
When I joined, the project was already underway and certain services were already in production, including IPTV in Moscow and satellite services. My main assignment was to lead and coordinate User Acceptance Testing (UAT) for the cable TV portion of the rollout. The difficulty was not only in the television technology. MTS had built its cable footprint partly by acquiring regional cable operators, so every region could have different network and operational characteristics, existing systems, business procedures, and acceptance stakeholders.
Initially the arrangement involved me as technical UAT lead with a separate test manager. In practice I later became the person coordinating and managing the UAT work directly, with assistance from customer specialists and engineers from subcontractors. Important subcontractors included Huawei for set-top-box hardware and related software/integration work, and CTI, a Russian integrator involved in the set-top-box GUI/software scope. I did not manage their organizations; I coordinated testing tasks and defect resolution across the relevant participants.
I prepared a detailed UAT manual, based partly on available templates and refined iteratively with the customer. I organized test preparation, executed tests together with customer personnel, tracked issues, and coordinated retesting and acceptance across multiple regions. This required communication with customer business, IT, and regional operational staff. Some acceptance work had to be carried out remotely by webcam and video conference, with a regional team showing the actual behavior of equipment and services while other people participated from elsewhere. That may sound ordinary now, but given the geographical spread, heterogeneity of the systems, and need for reliable acceptance evidence, it was a demanding coordination problem.
The cable TV service launch was successful. One small personal detail stayed with me: after the launch I even bought a cable set-top box for my parents, and the solution remained in use for years. That practical result was satisfying because I had spent so much time helping to test the service in real customer conditions.
This role strengthened my experience in coordinating multiple vendors and stakeholders without necessarily having formal line-management authority over them. It also gave me practical knowledge of television and fixed-service billing integration, which later proved helpful when a different operator asked me to look into an IPTV billing migration.
Qvantel / Ericsson / Beeline Russia — Front-End Solution Architecture
My next external consulting engagement, also arranged through Networkers, was with Qvantel as part of a much larger VEON Group transformation program. Ericsson was the prime contractor, while Qvantel, a Finnish company, was a subcontractor responsible for the front-end portion of the future digital BSS solution. The group-wide program was described as spanning seven operators and having an overall estimated value of up to US$1 billion. That was the scale of the program, not the monetary value of my personal responsibility or a contract I won.
Qvantel had a large back-office organization—more than 100 people across development, testing, analysis and other disciplines—supporting the wider effort. For individual operating companies, the working model included a small on-site representative group, typically covering project management, solution architecture and business analysis. I became the customer-facing Front-End Solution Architect for Beeline Russia, the Russian VEON operating company. I worked in Russia and Finland and regularly collaborated with the Qvantel and Ericsson teams.
My focus was understanding what Beeline's business and technical specialists needed from the front-end transformation and translating that knowledge into structured material for the solution teams. This involved more than a generic CRM screen. The work included business processes, customer interactions, CRM, Order Management, Product Catalog, and the UX/UI consequences of integration with contact centers, warehouses, eShop, mobile applications, and other commercial or customer-facing systems.
The on-site work required many customer meetings, process discussions and gap-analysis sessions. I worked directly with more than 20 customer-side subject-matter experts, both technical and business. The output included process diagrams, requirements, documented workshop results, and structured inputs for the Qvantel back-office architects and developers as well as Ericsson colleagues. I was the on-site architecture contact for these front-end discussions, not the owner of every underlying software domain. Specialized architects in the larger organization were responsible for the detailed solutions in their areas.
The Beeline Russia workstream did not reach full implementation. Requirements and business-process analysis had progressed, but the work had not necessarily reached the maturity required to say that complete high-level and low-level design packages were ready. The customer paused the Russian workstream amid broader concerns about the prime contractor's execution and confidence in the program. Other operating companies in the group continued or completed related activities, but those were not my assignments. Our Qvantel on-site team received positive feedback from customer SMEs, although that did not change the decision to pause the overall Russian workstream.
This experience gave me a clearer view of multi-vendor enterprise transformation: large central solution teams, small customer-facing groups, dependencies between front-end functions and back-end systems, and the importance of understanding what a customer actually does rather than simply presenting product capabilities. It also taught me the limits of a subcontractor's influence when decisions are being made at the prime-contractor or group-program level.
Fideware / A1 Belarus — BSS expert support and IPTV PoC
I returned to the operator then known as A1 Belarus (formerly Velcom), this time as a BSS consultant through Fideware, a smaller local IT company supplying experienced experts on a time-and-materials basis. The operator wanted people who already knew its Ericsson BSS infrastructure, without necessarily hiring each specialist as a permanent employee. Several of us had previously participated in the Ericsson implementation. Depending on the work, I operated independently or together with a team of approximately three experts.
Our main tasks were practical: support and configuration of Ericsson BSCS iX and related components, tariff and product configuration, rating and charging support, troubleshooting, faster issue resolution, and advice to technical or business specialists about whether particular service changes were feasible. Because we understood the system and its history, we could help the operator make changes with less investigation and uncertainty than a completely new team would have needed.
One especially interesting problem came from the operator's expanding fixed and mobile business. The operator had acquired Atlant Telecom, which had its own OSS/BSS environment for fixed and IPTV services. Some customers therefore had service and billing information distributed across different systems. The operator wanted to consider consolidating IPTV billing into BSCS iX, but the subscriber data contained many unusual and inconsistent records.
My earlier experience with MTS television services helped me understand the business context, while my database and Java background was useful for the technical side. The challenge was not simply copying subscriber data from one database to another. There were roughly 10,000–20,000 records to consider, and the real difficulty was designing a repeatable way to detect or handle non-standard cases while keeping the execution within an overnight window.
I proposed the migration approach, developed Java-based proof-of-concept scripts, and performed test migrations to check feasibility and performance. The PoC was successful, and business representatives confirmed that a full migration approach could be developed on that basis. However, the operator then shifted its attention to a larger BSS transformation and the Fideware engagement came to an end. I did not carry out or claim a completed full IPTV subscriber migration.
This was another example of how experience from one customer and technology domain could be valuable in a different assignment. It also gave me an opportunity to observe a BSS landscape over several years, after the large initial Ericsson delivery was over and the operator had to keep changing it in day-to-day business.
Kcell Kazakhstan — BSS transformation requirements and architecture
I joined Kcell, a major operator in Kazakhstan, as an external BSS Solution Architect / consultant. The consulting arrangement was facilitated through RP International, a UK staffing agency. The operator was preparing a major BSS transformation initiative with an indicative scale above US$10 million. Its legacy landscape included an aging Orga Systems platform used mainly for consumer services and a problematic Amdocs environment associated mainly with business customers. My responsibility was to help prepare the requirements foundation for procurement, not to design the selected vendor's final system or lead its later implementation.
The immediate challenge was the schedule. The operator wanted to collect and consolidate a very large set of requirements in only three weeks. We had over 1,000 raw requirements, coming from business, IT, legal, finance, marketing, customer care and other internal groups. The traditional method of meetings, spreadsheets and long email exchanges was too slow and made it difficult to control duplicates, revisions, questions and responsibility for answers.
I personally introduced a more structured collaborative approach using Atlassian Jira and Confluence. With this approach the external expert team and operator specialists could consolidate and clarify requirements more transparently. We classified the material with reference to TM Forum functional domains where appropriate, and turned the unstructured requests into a coherent RFI/RFP-ready requirements set. The work took about four weeks rather than the planned three—only a one-week extension despite the volume and complexity of the source material.
I also proposed extending the same style of structured collaboration to future vendor questions and answers. Instead of different vendors exchanging separate email and Excel versions with the operator, the idea was to make an accessible, structured Q&A workflow in Jira while preserving appropriate anonymity between competing vendors. This was a proposal for how later procurement interactions could be organized, not a claim that I conducted or managed the eventual vendor selection.
Using my product knowledge and public market information, I contributed views on potential suppliers and the initial vendor list. I did not take part in the actual later tender evaluation or shortlisting. Procurement was delayed following major changes in Kcell's ownership and investment decision processes, and the tender proceeded much later, after I had moved to other work. I cannot say exactly which version of our RFP documents was eventually used or what changes were made in the meantime. The contractual deliverables assigned to us were completed.
After the requirements work I also spent time sharing TM Forum concepts with the operator's enterprise architecture team. I discussed domain mapping, the SID information model, and attempts to represent relationships between customer and product information more systematically, using modeling approaches and tools familiar in the enterprise architecture community, including IBM Rational tooling of the period. This was knowledge transfer and practical discussion, not ownership of the operator's whole enterprise architecture program.
This assignment was an important step from hands-on BSS consulting toward business analysis, procurement preparation, structured collaboration and enterprise architecture. It demonstrated that a technical expert could create substantial value simply by making a difficult cross-departmental information process manageable.
Seavus / Whale Cloud / A1 Belarus — Business Analysis and Team Leadership
This assignment took me back to a customer whose systems and people I knew especially well. A1 Belarus, previously Velcom, was preparing another major BSS transformation, with the new vendor being Whale Cloud, associated with ZTE and its earlier ZTEsoft business. A1 belonged to Telekom Austria Group, and the program was strategically important to the vendor because success might support wider opportunities in the group. These are contextual observations, not claims that I personally directed the group-level strategy.
Whale Cloud brought a sizeable vendor team, but it also needed local business and technology knowledge. Seavus was subcontracted as an IT integration and business-analysis partner rather than being merely a personnel agency. The local team could help explain customer-specific business practices, legacy billing rules, language and communication issues, and expectations that foreign product teams might not immediately recognize. Seavus also had its own interest in developing broader integration cooperation with the vendor.
My earlier Ericsson BSCS iX implementation experience at this operator and my familiarity with its business and technical personnel were particularly useful. By agreement between the Seavus and vendor management, I was selected to lead the six-person Seavus business-analysis team. I coordinated its work and assisted communication with a larger vendor-side analyst group of approximately 25 people, but I directly managed only the Seavus team. I was not the formal manager of Whale Cloud's analysts and did not own the vendor's overall solution architecture.
In my formal individual BA scope I covered billing, invoicing, balancing, B2B and B2C payment processing, reporting, and integrations associated with those domains. Other business analysts handled their own domain integrations; Whale Cloud solution architects were responsible for the system-wide integration architecture. As a team lead, however, I tried to understand what was happening across the whole project so that I could coordinate dependencies and assist colleagues when cross-domain issues appeared.
A major challenge was not the technology itself but establishing a workable process for collecting, clarifying, tracking and documenting requirements. I introduced a structured requirements lifecycle and supported it with Jira and Confluence, so that decisions, changes, unresolved issues and ownership were easier to follow. This helped bring more order into communication among A1, Whale Cloud and Seavus. My own description at the time was that this work helped prevent a communication catastrophe: I use that expression to explain the difficulty, not as a quantified achievement.
I led or facilitated technical and business working sessions within my actual area, modeled processes, clarified requirements, performed fit/gap analysis and prepared inputs for subsequent high-level and selected low-level design. I also helped Whale Cloud architects understand the legacy customer's specifics. I did not lead CIO- or CTO-level workshops. When senior-level reporting was needed, I prepared materials requested through the vendor, including reports for senior customer management. I also could not claim to design the new ZSmart architecture myself, because at the beginning I was not sufficiently familiar with Whale Cloud's product to do that.
The project began officially on 1 July 2019. Activities continued until May 2020, when the COVID-19 pandemic interrupted and froze the work. This happened before actual delivery and rollout, so it would be incorrect to describe my process improvements as improving a completed implementation. The achievement was the organization and execution of the requirements and analysis stage, and better preparation for later design work. The engagement ended because of the pandemic-related interruption, not because I had completed a full BSS transformation.
At this time I also began learning some Chinese, partly because I expected more work with Chinese vendors in the future. I did not complete serious language training, but the attempt became relevant later when I worked closely with China-based Huawei colleagues.
Huawei — Presales Solution Architecture and customer development
This was the most significant change in the direction of my career. Earlier roles had given me extensive technical and customer-project experience, but I had rarely been directly involved in presales or commercial opportunity development. At Huawei I moved into a position where the central task was to understand customer needs, explain and position products, shape technical responses and proposals, and help the sales organization progress opportunities.
My working region covered Eurasia, the Middle East and Central Asia, with particularly intensive customer work in the CIS and Central Asia. I collaborated with customers and operators in Uzbekistan, Kazakhstan, Kyrgyzstan, Tajikistan, Georgia and Mongolia, as well as Russia. The practical work covered both large Tier-1 operators and growing operators with significant technology budgets. Depending on the customer and stage of discussion, the people in the room could be technical specialists, architects, business teams, financial or commercial managers, middle management, or executives such as the CEO, CTO, CIO, CFO and CMO.
Huawei's presales organization usually combined China-based product and headquarters solution architects with local customer-facing specialists who understood the customer, its legacy landscape, and local commercial or technical constraints. My role was primarily that of the local technical solution architect and customer-facing subject-matter expert. I was deeply involved in the preparation and review of solution proposals, but the end-to-end architecture was the result of collaboration between the sales, product, solution and delivery organizations. From the sales side I could act as the final reviewer of end-to-end solution documentation prepared or recommended by the delivery side. This does not mean I independently designed every technical component.
The product domains were broad: online charging and billing (OCS/BSS), CRM, FinTech products, AI Contact Center, AAA, VAS, provisioning and associated enterprise applications, with additional discussions about 5G charging and monetization. In 5G and IMS-related situations, my primary responsibility was understanding the requested business functionality and what it meant for BSS, tariffs, charging and integration. I was not the architect responsible for low-level core-network or radio-network design.
Much of my work involved collecting and clarifying customer requirements, explaining alternative solutions, preparing or reviewing technical responses to RFIs and RFPs, organizing and leading customer technical workshops, performing gap and scope analysis, assisting with estimates, providing input to proposals and pricing discussions, and supporting commercial negotiations. I coordinated with internal product, delivery and sales colleagues. I also read and analyzed internal libraries of project and competitor cases from other countries to understand competitors' strengths and weaknesses and contribute to internal positioning discussions. Competitive strategy was a team activity, not something I personally authored alone or approved as the final commercial decision-maker.
I was frequently the main customer-facing technical and business-solution SME during substantive meetings, but account managers generally owned meeting logistics and overall account coordination. I was not claiming that I had personally originated these opportunities through my own relationships; I occasionally used existing contacts to acquire useful background information, while most opportunity generation belonged to the account and sales organization. I also mentored junior presales and technical staff, organized BSS-related learning for younger colleagues, and conducted internal workshops to help Huawei account managers understand the products they were presenting. I sometimes used live product demonstrations and worked with RFI/RFP material as a practical way to train staff.
Main customer opportunities and their actual outcomes
Tele2 Kazakhstan. I supported two rounds of RFI and two rounds of RFP work, including requirements analysis and live presentations or demonstrations. Huawei was shortlisted during the relevant evaluations. The procurement did not proceed to a signed contract because the operator froze its next steps. This should not be represented as a deal that I won.
UMS Uzbekistan / Mobiuz. I participated in two RFIs and two RFPs, including analysis of the operator's legacy BSS landscape and its problems. I helped explain issues and possible approaches to customer management and contributed to technical and commercial discussions. Huawei reached shortlist stages, but the operator later froze procurement. Again, there was no final contract award, including for competitors in those stopped processes.
VEON Kyrgyzstan / Beeline Kyrgyzstan. I worked on a FinTech RFI opportunity. This was part of my growing exposure to products that are related to, but are not simply another component of, traditional telecom charging or billing.
VEON Russia / Beeline Russia. Here the presales process was different. There was no RFI stage for the activity in which I participated. Instead, I supported a roughly three-month proof of concept on a live operator network, including real integrations and testing of Huawei's OCS functionality. The PoC achieved its technical objectives by the end of 2021. Huawei subsequently stopped further continuation for external geopolitical or force-majeure reasons. A technically successful PoC should not be confused with a signed commercial implementation contract.
In addition to these major examples, I held technical and solution discussions, delivered product material, and explored opportunities with operators in Tajikistan, Georgia and Mongolia, as well as customers elsewhere in the region. Some opportunities were exploratory rather than full procurement exercises, and the level of commercial ownership differed from case to case.
Across the major opportunities I was involved in, the potential commercial pipeline exceeded US$50 million. This is a measure of opportunity value influenced or supported, not money personally sold, revenue booked, or contracts signed. In fact, several of the largest processes stopped or were frozen before a vendor could be selected. I want that distinction to remain unambiguous.
Presentations, public events and customer communication
An important part of Huawei work was learning how to present a complicated technical solution in a form useful for the audience. I gave dozens of customer workshops, executive presentations, product demonstrations, and public industry presentations, ranging from small specialist sessions to national-level technology and business events. Subjects included charging and billing, CRM, VAS, AAA, AI Contact Center and FinTech.
Examples that I remember clearly include being one of Huawei's principal speakers for FinTech at ICT Week Uzbekistan in 2023, being a main Huawei speaker at a CIO Club Uzbekistan event in 2025 (the year is 2025, not 2026), and participating as a speaker on AI Contact Center and FinTech at an interbank event organized by UzCard in 2025. I also presented Huawei software solutions to operator teams and management in several Central Asian countries. I was comfortable discussing solutions with people at different organizational levels, from technical domain experts to C-level leadership.
One lesson from these activities is that good technical product knowledge is only a starting point. The same solution may need to be discussed as an architecture, an operational change, a business capability, a competitive advantage, or a budget decision. I became more experienced in moving between these perspectives without losing the technical basis of the discussion.
Working with Huawei colleagues and learning new product areas
I worked closely with colleagues based in China. That exposed me to different working and communication habits and encouraged me to continue learning basic Chinese. I learned some words and phrases used in everyday cooperation, but I do not present myself as a fluent Chinese speaker. My view was that, if a business need justified it, I could resume structured study, starting toward a level such as HSK 1 and progressing from there.
For new Huawei product areas, I relied heavily on self-education, internal product training, documentation, and discussions with experts. I was moving between large BSS applications, FinTech, Contact Center solutions, AAA, VAS and newer charging requirements. The ability to research a product independently, understand how it fits into the client's existing systems, and explain its value became just as important as prior experience with any one vendor's software.
This Huawei period brought together the parts of my career that had previously been separate: deep technical experience, familiarity with customers and large software programs, requirements and solution work, public speaking, technical sales support, and commercial communication. I was not yet claiming to be the account director who owned every relationship, but I was increasingly involved in the work that helps a technical opportunity become a real business discussion.
Professional training and continuing self-development across the career
I have never regarded learning as something limited to a university degree or to a certificate. In most assignments I had to enter a new product, domain, or business environment and quickly build a useful working knowledge.
Formal professional training included instructor-led lectures and practical laboratory exercises in Oracle 11g Release 2 administration and RAC before the Uzbekistan database migration and official Genesys product and development courses during the Contact Center period. Huawei internal product training covered relevant solution portfolios. This training was complemented by self-study and practical project assignments. Familiarity with TM Forum, IBM Rational, and TOGAF concepts should not be mistaken for credentials or certification that were not earned.
In 2015, I completed approximately three months of part-time formal Machine Learning and Big Data Technologies training, combining lectures, practical exercises and labs. Coursework included datasets, Python, IPython notebooks and introductory work with Hadoop, HDFS, MapReduce, HBase, Spark and Kafka. This was relevant hands-on professional study, not a claim of advanced machine-learning engineering experience.
Across my career I have used or worked with Java, SQL, Python, Bash/Linux scripting, VBA, Oracle databases, virtualization platforms, testing frameworks and different enterprise systems. The level and recency of hands-on experience differ: for example, Java and SQL were major engineering tools in specific earlier assignments, while later positions were mainly architecture, analysis or presales oriented. I prefer to describe these abilities in context rather than imply that I have simultaneously been a full-time senior developer in every language.
My native language is Russian and I use English fluently in professional communication and negotiations. I studied some French in the past but have largely forgotten it. I also started Chinese while working with Chinese colleagues, as described above, but have not reached a level that would justify listing it as a professional spoken language.
What the roles taught me about the boundaries of responsibility
Several distinctions recur in my history, and I think they are important for an accurate professional presentation.
First, technical contribution and complete project ownership are different things. I developed a large GUI load-testing tool at Ericsson and helped fix performance blockers, but I did not manage the entire BSCS iX transformation. I was the on-site front-end architect for Qvantel at Beeline, but I was not the architect of every front-end or back-end system in the wider group program. At Seavus I led six analysts and helped coordinate with the larger Whale Cloud team, but I did not manage the vendor's 25 analysts or design ZSmart itself. At Huawei I influenced architecture documents, customer discussions, proposals and competitive positioning, but major solution and commercial decisions were shared with or owned by other teams.
Second, a procurement result and a project result are not the same thing. At Kcell I completed the requirements and RFP-preparation work; I did not run the delayed tender. At Fideware I proved an IPTV migration approach; the full migration was paused. At Qvantel we did valuable customer-facing analysis, but the Russian program was frozen before complete delivery. At Seavus we improved and executed the requirements-analysis process, but COVID-19 stopped activities before implementation. At Huawei we reached shortlists or technical success in several opportunities, but operator freezes and external restrictions prevented a contract in the cases described.
Third, the contracting relationship matters. Rustim employed or supplied me for projects performed through Step Logic and Borlas. Fideware supplied expert services to A1. Seavus was a real analysis and integration subcontractor in the Whale Cloud project, not just a staffing agency. Networkers arranged the external consulting engagements associated with Ericsson and Qvantel, and RP International was the intermediary for Kcell. Those staffing firms should not replace the actual project organizations in the story, but their role should not be misrepresented either.
Finally, learning a new domain repeatedly has been a real pattern in my career. I moved from scientific computing into virtualization and web-hosting products; from software QA into mobile billing; from billing into Contact Centers; from telecom billing into electricity retail; from engineering into national-scale government database migration; from BSS into television services and front-end digital transformation; and from implementation-side work into presales, FinTech and newer software products. Each time, the technical foundations and the ability to work with people in different roles made the transition easier.
How I see the next stage of my professional career
I am increasingly interested in work that combines solution architecture, presales, business architecture, and business development, rather than remaining exclusively within detailed engineering or purely technical architecture. I enjoy technical work and can still write code or automation scripts when that is a practical way to solve a problem. For example, I would be comfortable developing small Python-based tools to collect and structure publicly available customer information or support analysis. But the main direction I want to develop is the place where technical understanding is used to identify customer problems, structure opportunities, communicate with people, and help create commercially meaningful solutions.
I see a strong advantage in being able to speak both the technical and the business language. It is useful to understand a product in enough detail to discuss architecture and integrations with engineers, while also being able to discuss its business need, investment rationale and operational effect with managers. My career has included both substantial hands-on responsibility and extensive customer communication, and I want to build on both rather than discard either.
I have deep working knowledge of the CIS market and personal professional relationships with many customer representatives there, including senior management. I am also familiar with aspects of the Middle East, Africa, Asia-Pacific and Chinese markets, though familiarity should not be confused with having the same direct contact network in every region. I am interested in developing opportunities in CIS countries, potentially the Middle East and Latin America, and other markets where there is demand for enterprise technology and travel is reasonably safe. These are target customer markets, not necessarily places to which I want to relocate permanently.
My preferred work arrangement is flexible, remote or hybrid with business travel, and I am open to either employment or contract engagements. The acceptable amount and geography of travel depend on the actual business opportunity and personal safety conditions. I can work with large Tier-1 operators, but I am not limited to them; smaller customers can also be attractive if they have serious requirements and sufficient budgets for meaningful projects.
In the long term I would be interested in greater commercial responsibility, potentially in business development or sales leadership, while preserving a close connection to the technical side. I do not claim to have already been the final decision-maker for every sales opportunity. The next stage is about applying the combination I have developed: a strong technical foundation, experience across domains, independent learning, the ability to organize complex work, and the ability to communicate with customers and internal teams.
---