During brain storm sessions, the identified lead may want to initiate the necessary tools for each participant to bring along including a piece of paper and pencils to take down notes.
- Usually, these sessions should last an hour. The first 30 minutes will be open-ended questions and answers from the group.
- The next 15 minutes should be elimination of similar suggested questions or identified attributes by multiple participants.
- The last 12 minutes is to finalize the necessary needed questions and newly identified attributes to include into the existing systems.
- The last 3 minutes is use for addressing questions if not mentioned during the entire session. These questions if any, will be documented and discuss during the consecutive sequential schedule meetings for this project.
Brain storming is one of the tools recommended by 6-Sigma on how to reduce cluttering in order to accelerate with the documentation of the necessary agreeable requirements after presentations to Stakeholders of this project.
1.1 Causes and Solutions
Brainstorming is a method for generating ideas in a group situation. Teams and departments should use brainstorming when:
- Determining possible causes and / or solutions to problems.
- Planning out the steps of a project.
- Deciding which problem (or opportunity) to work on.
1.1.1 Running a Brainstorming Session
Provide a time limit for the session. Generally 30 minutes is sufficient. Identify one or more recorders to take down notes during the session. The recorders’ job is to write all ideas down (where everyone can see them, such as on a flipchart or overhead transparency) as they are voiced.
Choose either:
- a freewheeling format (share ideas all at once, list all ideas as they are shouted out) or
- a round robin format (everyone takes a turn offering an idea, anyone can pass on a turn, continue until there are no more ideas, all ideas are listed as they are offered).
- Filling and sharing feedback / questionnaire forms.
1.2 Establish the ground rules
1.2.1 Ground Rules
- Don’t edit what is said and remember not to criticize ideas.
- Go for quantity of ideas at this point; narrow down the list later.
- Encourage wild or exaggerated ideas (creativity is the key).
- Build on the ideas of others (e.g. one member might say something that “sparks” another member’s idea.
End the session when – everyone has had a chance to participate, no more ideas are being offered, you have made a “last call” for ideas, remember to thank all the participants.
1.2.2 Next steps
- Prioritize your ideas to help you decide where to start.
- Sort large amounts of information according to common themes (use post-its, one idea on each, all generated by individuals in response to a goal statement, within a limited time frame, and sorted into groupings).
- Remember brainstormed ideas may be based on opinion and data may need to be gathered to support or prove ideas.
- Some of these issues discussed may be miniscule very microscopic that the group would be able to finalize their analysis for those particular issues and ready to meet next to go through the expected results by comparing display values to what is produce by the application systems.
- The design efforts in enhancing existing related reports, modifies the process to generate such requested reports.
1.3 Identifying the Need of Applying Changes to COMMERCIAL ACCOUNT SYSTEMS
During brain storming sessions, it’s always prudent and necessary to capture suggestions and feedbacks which might be related to existing or identified problems from our users’ population including internal customers to these applications.
I recently ran across a tenacity, persistence, intransigence and inflexible condition which existed within COMMERCIAL ACCOUNT SYSTEMS that needed to be address immediately to reduce and avoid misunderstanding, misleading, miscommunication within the entire BANKING SYSTEMS and other partnership or business-to-business INVENTORY SYSTEMS where the naming of tables schemas within their RDBMS created abnormalities how the data, transaction threads were processed.
At first the problem appeared to be easy and solvable but the more I thought about the definition of the tables and operating sources where these data would be coming from, I realized it was going to involve multiple parties and experts from different subject areas of BANKING ACCOUNTING SYSTEMS.
Stepping through the process, the necessary requirements and data collections were the initial phase to identify where to start and also, how we could easily provide and satisfy our customer’s needs using JIT while the rest of the project is handled in a full lifecycle methodology when faced with issues like this.
In this situation a CHANGE MANAGEMENT (Maintenance Request) record and subsequence records were necessary, and meetings held with top management to scope, plan, dissect and forecast the project.
Within the IMS group, the following tables were identified for table names and definitions changes to reflect the actual nature of the data.
COMMERCIAL ACCOUNT SYSTEM consist of profitable, invested, credited, debited, assets and liabilities records including book entries and ledger transaction records.
The table names are misleading and have been interruptive, disturbing and a nuisance to business users who have been given the exposure of EIS nomenclature, categorization and architectural infrastructure without the complete understanding of why, where, and when the transactions actually occurred.
The reasoning behind this change is to eliminate misunderstanding both in their users’ communities and IMS groups. The architecture team should be aware of these changes and Management Initiatives should include, involve the planning, scoping, forecasting and implementation schedules of the project.
This project would need to use the normal full life cycle through implementation; and all necessary metadata changes should be reflective and maintained within the DATA DICTIONARY REPOSITORY accordingly following the DATA STANDARDS requirements.
Majority of the effort would occur in the Design phase of the project, coordinated by a dedicated Data Architect assigned to the project.
The COMMERCIAL_LOAN_TH tables needs change along with the ACCT_TYPE_CD value reflecting the nature of the data stored within these tables in the COMMERCIAL ACCOUNT SYSTEMS.
In the interim, JIT adhocs should be applied to apprehend the necessary changes.
| OLD | NEW |
| COMMERCIAL_LOAN | COMMERCIAL |
| COMMERCIAL_LOAN_TH | COMMERCIAL_TH |
| COMMERCIAL_LOAN_STMT_TH | COMMERCIAL_STMT_TH |
| ACCT_TYPE_CD (CLA) | ACCT_TYPE_CD (CMA) |
In short, the word LOAN should be removed and drop out of the identified table names.
No record length data should be affected with this MR(Maintenance Request). But ALL of the systems where these table names and ACCT_TYPE_CD are stated as those under the OLD column should be changed as recommended to reflect the names and values under the NEW column.
Initial research work is needed to take place to identify ALL the affected tables while team meetings are scheduled, organized and led by team leaders to make sure all necessary requirements are met, identified and captured by developers performing these search. The preliminary data investigation should include and involve database analysts and Database Administrators to go through all the connectivity systems and platforms, making sure all necessary tables, databases, extracts, ETLs are listed on the requirement documentation.
Possible extension of this project may result in cases where certain commercial threads (transaction records) as listed on the table definitions are not past into the COMMERCIAL ACCOUNT SYSTEMS. Extracts should be sources from those operating systems into the COMMERCIAL ACCOUNT SYSTEMS using the new ACCT_TYPE_CD as CMA.
Figure 1.3.1 Related IO of Commercial Banking Systems
Definitions for Aggregating Online Transactions as related to Commercial Account Systems (CMA).
By collecting input from online transactions systems such as SUNGUARD, FINTECH, COINBASE and other PAYMENT Systems.
Summarizing transaction records:
Amount values should reflect POSITIVE or NEGATIVE as reported on the INPUT datafiles. These may generate NEW COLUMNS and an EXPANSION of RECORD LENGTH resulting to CHANGE on TABLESPACE sizing and STORAGE capabilities.
Both Design and Production teams were notified, alert and scheduled recurring meetings to mitigate any such changes coming down the pipe (Waterfall methodology) during R&D (Research and Development).
Apply scheduled RUNS on summarized records to Extract – Transform – Load and ADD to CUSTOMER ACCOUNTS depending on the ACCT_TYPE_CD. ETL input transaction records from SUNGUARD, FINTECH, COINBASE depending on the CUSTOMER. Input data may be received DAILY; WEEKLY; BIWEEKLY; MONTHLY.
Both AMOUNT and CHARGES should be summarized before scheduled RUNS.
Deduct CHARGES from summarize AMOUNTS. SEND INPUT files INTO ACH DEPARTMENT depending on the ACCT_TYPE_CD. Records are then stored on the following tables – PI, DDA, TDA, CMA, INV based on the specific account type.
Keep in mind that as we walked through the different phases of the project, we all realized, it was very close to home as had originally imagined. Another condition to the puzzle was, with ANY BALANCE to the client, customer, entity or institution record, a MONTHLY STATEMENT should be sent to the rightful OWNERS.
These processes would help to limit the number of accounts per USER. Again, ACCOUNT NUMBER REUSE is to allow previous OWNERS to have their same ACCOUNT NUMBERS.
1.3.1 Distribution of Securities
As we drill down to the dying issue, I discovered some of their systems did not have either these columns SECURITY_TYPE_CD, SECURITY_CODE_NM nor the following code and name values for the above corresponding columns.
These classification and categorization of investment products were very important to derive with the mapping of these accounts as depicted in figure 1.3.1.
| SECURITY_TYPE_CD | SECURITY_CODE_NM | |
| ACH | Automated Clearing House | |
| ICS | Investment Credit Securities | |
| WMD | Winning Money Distribution | |
| SPG | Structured Product Group | |
| CCO | Collateralized Credit Obligations | |
| IPN | Index Profitability Notes | |
| PPP | Profitability Pass-thru Payments | |
| MBSO | Monetary Bypass Systems to Owners | |
| CDO | Credit Deductible Obligations |
Table 1.3.1.1 Security Type Code valid values.
1.3.2 Decision Making During Corporation Share Split
Most corporations rely, depend and thrust subtle resolutions to their corporate financial statements without actually taken the burden to reflect on certain factors such as dividends when their company stocks (shares) splits.
Splits do not occur in most cases on regulated timing / scheduled but base on their corporation, company or incorporation’s performance / merger procedures such as convergence, absorption, mergence or combination of multiple corporations to restructure overheads by the owner(s), reducing the number of officers hence busting the overall performance by identifying newly improve methodology to accumulate profitability per investors / owners of either or companies or shares.
Resolutions generally indicated by Financial Adaptive Finite Quantitative (FAFQ) platforms may not indicate the In-House Financial Statements for such corporations.
- Many as often, the most debated, disputed column value amongst Economists, savvy IT specialists with an incline to actuate / accrued [of sums of money or benefits) be received by someone in regular or increasing amounts over time] logics or Financial Mathematicians have always been the DEBT amount.
The DEBT amount on total number of available shares multiplied by the price per share (P/S) should NOT be regarded when considering performance of any corporation. Neither should the company’s bottom line performance be evaluated by considering the outstanding shares.
When considering the total number of shares including outstanding shares, the figure associated with or display on the “DEBT” column should be regarded as positive. In this case, trailing issues regarding the distribution of profitability’s should not be apparent or questionable to its holders.
During corporations, companies, or incorporated stock (shares) splits, the dividend is usually the inverse (vice versa) of the split ratio. In case the value is very high compare to the value per share, an additional amount of share could be distributed per holders / employees.
Let’s go through a simple example for instance GOOGLE, Inc with a share price of $2260.00 and had to split 20:1; the resulting table is a typical example on how the dividends would be reflected and further distributed.
| EQUITY | CURRENT SHARE PRICE | SPLIT RATIO | RESULTING SHARE PRICE |
| GOOG | $2260.00 | 20:1 | $113.00 |
| FOR DIVIDEND | |||
| CURRENT DIVIDEND VALUE | RATIO (VICE VERSA) | RESULTING DIVIDEND VALUE | |
| IF | $2.00 | 20:1 | $0.10 |
The shareability, distribution and usability of the resulting dividend value would eventually drop down the final reporting value. At that instance, the board of directors is deemed to decide what value to agree on as dividend which should not be ≤ $2.00/20 at a minimum.
It’s always interesting when such minimal arithmetic consumes our precious time, while socializing over the latest pastries, traveling from unnecessary distance just to decide when to publicize such crucial information as pertinent to stock holders as well as employees.
Web2goTech 