Understanding from a PM's Perspective: Core System Operation Record 4: Deciphering the Current Configuration — Overview of the Kurameso Core System Architecture

In this series, I have been organizing core system operations from a PM's perspective, introducing management through annual design and the concept of treating architecture as a "history of decision making."

So what does the actual structure of current core systems look like?

In this article, I will use Classmethod's core system as an example to organize the roles and dependencies of each system while providing an overview of the architecture. I will summarize the current configuration to serve as a reference resource for internal team members.

1. Core System Overview

First, I'll show the overall picture (partially excerpted) of the current core system configuration.

This structure can be divided into the following major areas:

• Sales and Customer Management
• Contract and Billing Management
• Support Management
• Financial Accounting
• Resource Management

Each system cooperates while fulfilling its respective role.

Below, I'd like to discuss the background of this configuration by focusing on several key characteristics.

2. Characteristics of the Core System Configuration and Its Background

Coexistence of HubSpot and Salesforce

We use both HubSpot and Salesforce, which are SaaS products for SFA/CRM. This probably seems quite unusual at first glance. Why use two SaaS products with nearly identical functions and roles?

To understand this, I need to explain the history.

Classmethod introduced Salesforce about 10 years ago. Since this was before I joined the company, this is based on what I've heard, but at that time, Classmethod's AWS resale business was growing significantly, and they couldn't keep up with creating invoices for customers (around 300 per month), causing staff to work overtime and weekends.

The bottleneck in operations was that information was scattered across various files and systems, preventing centralized data management. This led to:

• Ambiguous business workflows
• Scattered customer and billing department master data with inconsistent formatting
• Contract information being scattered and not linked to master data
• Data discrepancies between different ledgers (start dates, contract numbers)
• Numerous human verifications and communications required due to these issues

By introducing Salesforce, they were able to centralize data management, organize business workflows, and promote automation.

For more details on this, please refer to the following article written by Mr. Ueki:
Developers.IO 2017 Session "A1. Technology Supporting Classmethod's Billing - Survival Strategy of a 40-year-old Engineer" #cmdevio2017

The important point is that at Classmethod, Salesforce was introduced in the context of solving AWS resale billing challenges.

Introduction of HubSpot

As mentioned in the previous section, Salesforce was introduced to address AWS resale billing challenges. This centralized customer master and billing data in Salesforce. However, as the business developed further, the following problems emerged:

1. Customizations focused on AWS resale billing made it difficult to use Salesforce effectively as an SFA
2. The heavy cost burden of SaaS license fees (Salesforce licenses) increasing in direct proportion to sales staff growth
3. Difficulty in sharing and utilizing sales information company-wide (to promote cross-selling and reduce cancellations)

To solve these problems, HubSpot was introduced because its license structure didn't charge for data access. Additionally, MA (Marketing Automation) that had been using Pardot+Salesforce was migrated to HubSpot. This enabled an SFA environment not tied to AWS resale, cost containment, and company-wide data utilization.

Sales Portal Connecting HubSpot and Salesforce

With the introduction of HubSpot, SFA utilization not tied to existing business advanced. However, at the same time, new problems emerged, such as similar information being stored and managed in duplicate with "customer (account)" in Salesforce and "company" in HubSpot.

From the flow so far, you can understand that HubSpot contains "soft information" including sales and proposal status, while Salesforce holds "hard information" only for contracted and billable items. The problem was data dispersion and duplicate management, especially since Salesforce was accessible only to a small number of license holders, necessitating some kind of integration mechanism.

Therefore, a React-based web application called the Sales Portal was developed from scratch as a system to provide cross-access to HubSpot, Salesforce, and other information resources needed for sales activities. The reason for not adopting a new SaaS was to avoid increasing license fees with the growth of users (≒ number of employees). Additionally, by implementing authentication and authorization with EntraID+AWS Cognito, the Sales Portal itself became available to the entire company.

3. Role of Salesforce

As we've seen so far, HubSpot handles the entry point for sales activities. On the other hand, Salesforce plays the central role in the overall core system.

Salesforce primarily manages the following information:

• Customer master data
• Business opportunities and projects
• Contract information
• Billing information

These can be considered "business data" confirmed as a result of sales activities. While HubSpot handles "soft information" including intermediate stages of sales activities, Salesforce centralizes "hard information" such as contracts and billing.

The reason for this role division is due to the background that Salesforce was originally introduced to solve billing challenges in the AWS resale business. Therefore, in the current core system configuration, Salesforce functions not so much as a sales tool but as a core data management system centered on contracts and billing.

As can be seen in the diagram, Salesforce also functions as a hub for integration with other systems. Multiple systems such as the Sales Portal, cloud resale service site, and financial core system connect data through Salesforce.

4. Integration with Peripheral Systems

The core system is not complete with Salesforce alone but supports the entire operation through integration with multiple peripheral systems.

First, we use Zendesk for support operations. Zendesk primarily manages support cases and integrates with the cloud resale service site. This enables unified management of inquiries from customers with active contracts.

For revenue and accounts receivable management, the financial core system is responsible. Billing data managed in Salesforce is linked via CSV format, and sales and accounts receivable are managed on the financial core system side.

Furthermore, the resource management system manages planned and actual work hours. This information is referenced from the Sales Portal and used as supplementary information for sales activities and case management.

As you can see, the core system is not a single system but consists of multiple systems sharing responsibilities.

5. Characteristics of the Current Configuration

The configuration we've looked at so far has several characteristics.

First, it is centered around SaaS. By combining SaaS such as HubSpot, Salesforce, and Zendesk, we utilize functions appropriate for each domain.

Second, the roles are clearly divided by system.
HubSpot manages sales activity information, Salesforce manages core data such as contracts and billing, and the financial core system manages revenue and accounts receivable.

Third, there are multiple methods of system integration.
REST API is used for the integration between HubSpot and Salesforce, while data integration via CSV files is used with the financial core system. This kind of mixed configuration of API and file integration is relatively common in actual business systems.

And one more important point is that this configuration was not designed from the beginning.
It has reached its current form through introducing new systems and adjusting the roles of existing systems in response to business growth and operational challenges. As mentioned in Episode 3, architecture is formed by the accumulation of decisions rather than being created from an "optimal solution."

6. Summary

In this article, I have organized the overall structure of the current core system and its background.

Classmethod's core system is configured with Salesforce at the center, integrated with multiple SaaS and peripheral systems. This configuration was not designed all at once but was formed gradually in response to business growth and operational challenges.

In operating such existing systems, rather than designing an ideal architecture from scratch, it's important to understand the current configuration and focus on making improvements based on it.

In the next article, I will organize from a PM's perspective how to proceed with improvements and evolution based on the existing core system configuration.