When discussing top tech companies in Thailand, it is almost impossible not to mention KBTG or KASIKORN Business-Technology Group, a company that offers a truly positive work environment.
To foster a great working atmosphere, the organization offers numerous employee benefits, a multitude of job positions for individuals to choose from based on their qualifications and preferences, and continual challenges in our day-to-day role.
If you ever feel like your current career path is not fulfilling, the organization also offers a program called “KBTG Internal Mobility”, which grants employees opportunities to change positions within the organization.
Starting Point From SE
My journey as a KBTG employee began when I converted from IBMSD workers on January 4, 2016, the day the organization was created. This makes me part of the pioneering generation of employees.
After the transition, I started working at KBTG as an Advanced Software Engineer, commonly known as a Programmer or Systems Developer in other companies. My primary responsibilities involved maintaining and developing systems related to Bill Payment, Fee Charging, RMS, CH-Register, and LMS, all programmed using the COBOL language on a Mainframe Computer.
So many words I used in that paragraph are proofs to how much time has passed
What does a Software Engineer (SE) do?
A Software Engineer (SE) is responsible for various tasks. Our main responsibility was to maintain and develop programs coded in COBOL language on Mainframe computer. All applications we oversaw used a database called as DB2 to store data. For the development of front-end programs, we used .NET language. In this aspect, fellow SEs would be assisting with programming the user interfaces to facilitate customer data input, as using COBOL for user interfaces would result in less aesthetically pleasing and less user-friendly design.
COBOL programs would be executed in a consecutive order. Variables were required to be declared and it would use commands that were similar to English sentences when coding. The compiler used JCL (Job Control Language) to check the program’s syntax. Data files, which are primarily used for development on the Mainframe computer were typically File-based and included Sequential, Random, and Dynamic file types.
To support the system properly, we needed to cooperate with Business Analysts (BAs), who conducted meetings to gather requirements from users. Subsequently, they relayed these requirements to Software Engineers (SEs) to determine what needed to be developed, enhanced, or modified. Once we received the requirements from the BAs, we performed Impact Analysis collaboratively, considering both the open and Mainframe aspects. This analysis helped us understand how each development or modification would impact user interfaces or programs and which applications were affected. We then scheduled meetings and discussions with the teams responsible for relevant applications so that they could analyze the impact that could possibly occur, whether it involved program modifications or simply joint testing without program changes. Sometimes, we might not have all the information about some applications, so it was essential to hold meetings to discuss with all relevant parties to get all information or to gain a mutual understanding of issues or solutions. This way, we were able to avoid any unforeseen consequences after the system went into production.
Typically, the primary responsibilities of a Software Engineers (SEs) after conducting Impact Analysis involve assisting in the man-day evaluation for program development. This includes performing Unit Testing and participating in System Integration Testing (SIT), User Acceptance Testing (UAT), and ultimately deploying the system into production. This data was then used by Business Analysts (BAs) and Development Managers (DMs) to assess man-day in more detail and made an Effort request.
Once all assessments were completed, we proceeded with program development, perform Unit Testing, code JCL (Job Control Language) to sequence program execution, create Job Run Sheets to organize the execution order of each job, ensuring alignment with the workflow we have outlined.
Additionally, we established interdependencies for file transfers among various related applications. We would have to schedule a meeting with the IT Operation Manager once the job run sheet was finished, to go over and clarify things in order to reach a common agreement that would allow IT Operation to move forward and set up Control-M for job execution accurately. Once IT Operations configured Control-M, we performed testing by releasing Control-M to execute the entire workflow using the test data. This validation checked whether jobs and programs ran smoothly without any issues and ensured that there would be no defect during the process. This was also a part of rechecking if the IT Operation had set the Control-M correctly.
When we progressed from the Unit Test phase to System Integration Testing (SIT) and User Acceptance Testing (UAT), the primary responsibility of SE was to oversee and fix defects in the program where errors occurred. If UAT was successful and received sign-off from the users, the SE proceeded to write a Deployment Document and initiated the change process. Once the Deployment Document was completed, a review session was conducted with IT Operations and Development Managers (DMs) to ensure the correct deployment.
After that, the program would be baselined to be used in the deployment process. Before the deployment, an Integration Verification Test (IVT) was conducted to verify that the program and jobs being moved to production were error-free and no issues would occur in the production phase.
Another significant responsibility of SEs like us was to fix incidents that occurred in the production phase, which could always happen days and nights, depending on the jobs and systems we were responsible for. So, we were required to provide support 24/7. Sev 1 incidents, in particular, are known to be critical. It could have been widespread consequences if left unresolved for too long. Therefore, our mobile phones must be within reach at all times, whether it was during sleep or while awake.
There was once a time when we worked on the Inward Remittance system, which was one of the biggest projects that I got to participate in. Our team contributed to the program development. We coded numerous programs, had a complex job flow, and created detailed Job Run Sheets. There were nearly 300 jobs ongoing. In the very same year, our team received a team award for “Inward Remittance Project”, and it was such an honor to be a part in developing Mainframe systems that were on par with open-source programs.
Transitioning From SE to Working as a BA
After working in the position of SE for about 2 years, the company started implementing a policy to sunset the Mainframe within 3 years. This decision was made due to the relatively high cost and various limitations associated with developing systems on Mainframe. Although Mainframe systems had the advantage of processing large amounts of data quickly, the company did not want to bear the high expenses and aimed to embrace new technologies.
Although it seemed unlikely that the sunset could be completed within the 3-year timeframe, the statement somehow led me into thinking that a new direction other than being a programmer might be a better fit to my lifestyle. Besides programming, SEs had to be on-call to support incidents, leading to irregular working hours, making it hard to maintain the work-life balance. Furthermore, we needed to learn new programming languages that the company was using for development, such as Go, Python, and Java. But it proved to be a challenge to a person of my age comparing to a new and younger generation.
During that time, our DM took over the responsibility of managing the Trade team’s application, TradePro EPA. This system was part of the fund transfer process within the K PLUS app, including the AFMS system, which handled bulk data file transfers for salary deposits into employees’ accounts. During that time one of the colleagues was about to resign, so I had the opportunity to transition to this role. Additionally, there were requirements for updating the GPI version according to SWIFT’s annual policy.
Once there was a vacancy in the position of Business Analyst (BA), I volunteered to switch my position to fulfill the role to help design the system’s user interfaces, discuss requirements with users, and create specifications to assist SEs with programming and testing. When my supervisor saw that I was capable of the role, we began discussing a new career path. I made it clear that I no longer wanted to be primarily involved in programming and preferred working as a BA. At that time, my organizational position remained as SE, but I assumed the role of a BA within the project.
I started transitioning all works that related to Mainframe systems to be managed by the other team members. Afterward, I assisted the new DM in charge of the TradePro EPA and AFMS systems, replacing our previous supervisor. At this point, I fully embraced the role of BA. However, I still had continue to assist SEs in overseeing source code control, opening changes, reviewing deployment documents, and providing support for incidents during the day.
The TradePro EPA, AFMS, and TradeNa systems had been developed over a long period. All of them, were somewhat outdated and limited in functionality, leading to frequent incidents and unsatisfied customers. Our users requested the development of a more modern money transfer system that could meet their various needs, which the old systems couldn’t fulfill. This new system, called GPS (Global Payment System), marked the beginning of our work as BAs. Our tasks included conducting workshops to gather requirements from users, creating screen prototypes, designing crucial documents and reports. We also conducted workshops with users, performed impact analysis, and had the opportunity to learn about SWIFT systems and various aspects of the BA role.
As the GPS system was a new money transfer system developed by Vietnamese developers, we had to create a Functional Specification (FS) to explain the requirements to the Vietnamese BA team. We elaborated on the FS and assisted the Vietnamese developers in testing the program. Additionally, we explained the requirements to test team and assisted them in reviewing the test cases to be used in testing. We logged defects during the System Integration Testing (SIT) phase and facilitated communication between the development team and test team to ensure that the SIT proceeded as planned. We provided assistance with defect fixing during the User Acceptance Testing (UAT) phase, where we helped users review test cases and collaborated with the Vietnamese Development Team to address all defects. Our role also involved reviewing the Deployment Document for the production release.
Transitioning to Test Quality Assurance through KBTG Internal Mobility
At KBTG, there is a program called KBTG Internal Mobility that offers employees the opportunity to switch career paths within the organization. Various teams or areas within the company will come share their way of work and the positions they are looking for, along with the required qualifications. Finding that working on application development could create challenges in planning for vacations or extended leaves because project delays are quite common, I wished to transition to roles related to process management, as I believe it would provide a more specified work schedule in the long run.
After attending the talks hosted by KBTG Internal Mobility program and listening to presentations from various teams, I was particularly interested in the field of testing. However, when I discussed it with a colleague, they warned me that it might be too drastic of a career change and could potentially slow down the progress in my current roles, as I would need to start everything from the very beginning again. Around the same time, I had the opportunity to speak with a Test Manager who suggested that the Test Quality Assurance (TQA) team was in need of new members. The head of TQA expressed confidence in our ability to excel in this role, even though testing was entirely new to me and required obtaining a professional certificate. After careful consideration, I decided to take on the challenge through the KBTG Internal Mobility program. I informed my team about the transition at least one month prior to the position shift to ensure that the transition process could be done without a hassle.
When transitioning to a new role within KBTG, there was no reduction in Capability or Band progress. The change in position aligns with the specific requirements and responsibilities of the new team. Upon joining the TQA team, I had to put in significant efforts to learn and adapt because most aspects of the job were entirely new to me. Our team leader assigned me to teach simple topics to the junior members who were training in the Tech Kamp program. I also assisted with coordinating and teaching. I also acted as a ‘Buddy’ to help mentor all Tech Kamp participants. At the same time, I prepared for certification exams, which were a fundamental requirement for the role, and successfully passed both the ISTQB Foundation and ISTQB Test Manager exams. On another happy note, the collaboration with the Tech Kamp participants contributed to our team receiving a team award for “Build Capability”.
This year, my manager assign me to design the Test DI (Deliverable Item) Templates to replace the outdated. Designing these templates is a relatively new and challenging endeavor for me. I also has the opportunity to create a training course for SQM, a task I have never experienced before. Although it presents quite a challenge, I found it enjoyable. It has become valuable learning experience both for me and the participants.
Currently, I am still part of the TQA team, and I would like to emphasize that at KBTG, if you’re interested in trying out new roles, the organization is always open to provide opportunities for everyone. You can directly discuss your interests with your manager or approach the team you wish to transition to, then inform your current team about your intentions. Alternatively, you can explore the KBTG Internal Mobility program, where you can browse for available job positions and submit your preferences through the system. Once you complete this step, the HRBP team will contact you to arrange an interview. With these options, you can explore working in areas of your interest without the need to resign. For other people, if you’re interested in joining a tech company that provides you with this kind of learning opportunity or flexibility, learn more about KBTG and apply for opening positions using the link below.
For those who enjoy this article, don’t forget to follow Medium: KBTG Life We have knowledge and great stories from KBTG folks ready to be served here first.
