Post edited 7:20 pm – September 4, 2010 by wspademan
We aim to complete by December 1, 2010 a detailed plan for Common Good Bank system IT. Here is the original outline of what we need (Google doc), updated.
Kurt King has already expanded enormously on these specifications and proposed data models for some components: CGB Draft IT Plan 2009
I propose that we hold on to those details, but back up a step for a while, keeping discussion at a higher level (less detail) by focusing on the original outline, while we figure out what to write from scratch, what software to adopt without change, and what open source projects and components to modify or branch.
Richard Kerver has done some extensive research on open source options. See our meeting minutes here.
Let's use this IT Forum to discuss IT matters (and avoid using email for discussion, most of the time). Please comment on this proposal or suggest solutions to specific lines in the outline, as a reply to this post.
Post edited 9:37 am – September 6, 2010 by wspademan
Paraphrasing Richard's proposals, but splitting (1), (2) and (5):
1a) depositor services, including transfers, checking, cards (by 5/2011. OUTSOURCE)
1b) inter-bank transaction processing, statements to customers (by 5/2011. OUTSOURCE)
2a) the CGB accounting system, CRM, GL, HR/PR, Procurement, transaction processing within CGB (ASAP. ADOPT*)
2b) information sharing and preemptive transactions, for transaction processing within CGB (BY WHEN? HOW?)
3) loans (by 12/2012. CREATE)
4) partnerships, banking relationships, related services (by 12/2012. BUY)
5a) internal accounting, policies, procedures, reporting (by 1/2012 when we have our first audit. CREATE? ADOPT? BUY?)
5b) everything else: business intelligence, decision support, etc. (by whenever. CREATE? ADOPT? BUY?)
* For the CGB accounting system (2), adopt one of these open source ERP candidates: JFire (Richard's favorite), Opentaps, Adempiere, Openbravo
Here's what I think:
1a. Agreed. (by 5/2011. OUTSOURCE)
1b. I disagree. (CREATE)
Transactions. We will need to react in real time to inter-bank transaction requests — that will require customization. Ideally, if we can hire a Credit Union (or more likely a CUSO) to provide this service and customize the software, let's do it that way at least in the short term.
Statements. We will want to CREATE our own statements in any case (starting probably with some generic open source financial reporting) because we want to report things that no other bank reports.
2a. Agreed. (ASAP. ADOPT*)
In fact, almost everything we want to do can be structured as accounting, if we set up the accounts right. It will be essential that accounts can be grouped in at least two ways: by type (eg checking account, loan account, interest income, etc) and by owner (viz specific community division or specific customer). For example, we will need to set policies and report on a single community or customer (eg the ratio of stock to deposits in Amherst, MA) AND on account balances across ALL communities and customers (eg total CGB checking account balances or total stock sales). Some "parent" accounts will have children by type and some will have children by owner. If we choose accounting software that allows two or more charts of accounts containing identical bottom-level accounts, then we're all set (otherwise we will have to CREATE such a capability, or do a lot more arithmetic — either way, it will be less secure).
2b. (by 5/2011 CREATE)
3. I disagree. (ASAP. ADOPT*)
The only thing we want to do with lending that is unusual is WHO DECIDES. We can use standard loan-management software.
4. Mostly Agreed. (by 12/2012. BUY)
However, partnerships with credit unions (and possibly banks) is an exception and should be seen as part of 1b and 2a.
5a. Agreed. (by 1/2012. ADOPT/BUY)
Software for managing these things should be pretty standard, so we won't have to create it (unless we want to, at our leisure after the bank opens)
5b. Agreed. (by whenever. CREATE/ADOPT/BUY)
No hurry
* I will not be looking at any specific ERP candidates. What happened to Kuali? (Richard did you decide it is too complicated?)
Paraphrasing Richard's proposals, but splitting (1), (2) and (5):
1a) depositor services, including transfers, checking, cards (by 5/2011. OUTSOURCE)
1b) inter-bank transaction processing, statements to customers (by 5/2011. OUTSOURCE)
2a) the CGB accounting system, CRM, GL, HR/PR, Procurement, transaction processing within CGB (ASAP. ADOPT*)
2b) information sharing and preemptive transactions, for transaction processing within CGB (BY WHEN? HOW?)
3) loans (by 12/2012. CREATE)
4) partnerships, banking relationships, related services (by 12/2012. BUY)
5a) internal accounting, policies, procedures, reporting (by 1/2012 when we have our first audit. CREATE? ADOPT? BUY?)
5b) everything else: business intelligence, decision support, etc. (by whenever. CREATE? ADOPT? BUY?)
* For the CGB accounting system (2), adopt one of these open source ERP candidates: JFire (Richard's favorite), Opentaps, Adempiere, Openbravo
Here's what I think:
1a. Agreed. (by 5/2011. OUTSOURCE)
1b. I disagree. (CREATE)
Transactions. We will need to react in real time to inter-bank transaction requests — that will require customization. Ideally, if we can hire a Credit Union (or more likely a CUSO) to provide this service and customize the software, let's do it that way at least in the short term.
Statements. We will want to CREATE our own statements in any case (starting probably with some generic open source financial reporting) because we want to report things that no other bank reports.
2a. Agreed. (ASAP. ADOPT*)
In fact, almost everything we want to do can be structured as accounting, if we set up the accounts right. It will be essential that accounts can be grouped in at least two ways: by type (eg checking account, loan account, interest income, etc) and by owner (viz specific community division or specific customer). For example, we will need to set policies and report on a single community or customer (eg the ratio of stock to deposits in Amherst, MA) AND on account balances across ALL communities and customers (eg total CGB checking account balances or total stock sales). Some "parent" accounts will have children by type and some will have children by owner. If we choose accounting software that allows two or more charts of accounts containing identical bottom-level accounts, then we're all set (otherwise we will have to CREATE such a capability, or do a lot more arithmetic — either way, it will be less secure).
2b. (by 5/2011 CREATE)
3. I disagree. (ASAP. ADOPT*)
The only thing we want to do with lending that is unusual is WHO DECIDES. We can use standard loan-management software.
4. Agreed. (by 12/2012. BUY)
5a. Agreed. (by 1/2012. ADOPT/BUY)
Software for managing these things should be pretty standard, so we won't have to create it (unless we want to, at our leisure after the bank opens)
5b. Agreed. (by whenever. CREATE/ADOPT/BUY)
No hurry
* I will not be looking at any specific ERP candidates. What happened to Kuali? (Richard did you decide it is too complicated?)
Paraphrasing Richard's proposals, but splitting (1), (2) and (5):
1a) depositor services, including transfers, checking, cards (by 5/2011. OUTSOURCE)
1b) inter-bank transaction processing, statements to customers (by 5/2011. OUTSOURCE)
2a) the CGB accounting system, CRM, GL, HR/PR, Procurement, transaction processing within CGB (ASAP. ADOPT*)
2b) information sharing and preemptive transactions, for transaction processing within CGB (BY WHEN? HOW?)
3) loans (by 12/2012. CREATE)
4) partnerships, banking relationships, related services (by 12/2012. BUY)
5a) internal accounting, policies, procedures, reporting (by 1/2012 when we have our first audit. CREATE? ADOPT? BUY?)
5b) everything else: business intelligence, decision support, etc. (by whenever. CREATE? ADOPT? BUY?)
* For the CGB accounting system (2), adopt one of these open source ERP candidates: JFire (Richard's favorite), Opentaps, Adempiere, Openbravo
Here's what I think:
1a. Agreed. (by 5/2011. OUTSOURCE)
1b. I disagree. (CREATE)
Transactions. We will need to react in real time to inter-bank transaction requests — that will require customization. Ideally, if we can hire a Credit Union (or more likely a CUSO) to provide this service and customize the software, let's do it that way at least in the short term.
Statements. We will want to CREATE our own statements in any case (starting probably with some generic open source financial reporting) because we want to report things that no other bank reports.
2a. Agreed. (ASAP. ADOPT*)
In fact, almost everything we want to do can be structured as accounting, if we set up the accounts right. It will be essential that accounts can be grouped in at least two ways: by type (eg checking account, loan account, interest income, etc) and by owner (viz specific community division or specific customer). For example, we will need to set policies and report on a single community or customer (eg the ratio of stock to deposits in Amherst, MA) AND on account balances across ALL communities and customers (eg total CGB checking account balances or total stock sales). Some "parent" accounts will have children by type and some will have children by owner. If we choose accounting software that allows two or more charts of accounts containing identical bottom-level accounts, then we're all set (otherwise we will have to CREATE such a capability, or do a lot more arithmetic — either way, it will be less secure).
2b. (by 5/2011 CREATE)
3. I disagree. (ASAP. ADOPT*)
The only thing we want to do with lending that is unusual is WHO DECIDES. We can use standard loan-management software.
4. Agreed. (by 12/2012. BUY)
5a. Agreed. (by 1/2012. ADOPT/BUY)
Software for managing these things should be pretty standard, so we won't have to create it (unless we want to, at our leisure after the bank opens)
5b. Agreed. (by whenever. CREATE/ADOPT/BUY)
No hurry
* I will not be looking at any specific ERP candidates. What happened to Kuali? (Richard did you decide it is too complicated?)
We have set a year-end goal (Nov-Dec) to bring closure to the
planning phase and to initiate a development phase. ( The suggestion for
some continued open ended process past year end does not work for me.)
————
The aspects of CGB-IT:
1> depositor services, including transfers, checking, cards, transaction processing, statements, etc.
2> the CGB accounting system, CRM, GL, HR/PR, Procurement, etc
this is where the question of open-source ERP comes into play; need to make that decision because its core
3> loans
this is what makes the bank interesting and fun
where the question of mifos, micro-finance, alternative currencies, etc.
what distinguishes CGB from all other banks is us doing something unique with the money entrusted to us
in terms of who, what, where and why – the sustainability agenda
4> partnerships, banking relationships, related services
ultimately, a full-featured bank would offer a variety of services
here's where the SAP vision for a universal SOA architecture comes into play
the CGB is both a consumer and provider of SOA services
we succeed or fail on whether we remain competitive in this dimension, so architecture and industry standards are important
some significant buy-in of business-to-business, bank-to-bank, brokered trade
5> everything else that Kurt outlines in the original CGB-IT proposal that he worked on
state regulatory authority, reporting requirements
business intelligence, decision support, etc.
Time-line:
<1> and <2> out of the gate, done ASAP, no latter than May, 2011
suggests outsourcing <1> completely
suggests straight forward adoption & implementation of one open-source ERP candidates:
> JFire (my current favored choice)
> Opentaps
> Adempiere
> Openbravo
<3> is where we invest most of the early work – its our market differentiator, so has to be done really well
by the end of 2012 (1 year of development, 1 yr of production repair)
<4> and <5> would also need to be completed early, within the first year of bank operation
meeting our first bank audit (both internal and external) would
need to be a high priority for everyone involved, but not out of the
gate
———-
Some additional perspective on the concept of a chaordic organization:
Human beings like order, so are attracted to computers in our life,
but are tending to chaos, because we fundamentally find all systems of
imposed order repugnant. Life is always messy, including human
enterprise. Both chaos and order must be acceptable – life is a
paradox.
"The portmanteau chaordic refers to a system of governance that
blends characteristics of chaos and order. The term was coined by Dee
Hock the founder and former CEO of the VISA credit card association. The
mix of chaos and order is often described as a harmonious coexistence
displaying characteristics of both, with neither chaotic nor ordered
behavior dominating. The chaordic principles have also been used as
guidelines for creating human organizations — business, nonprofit,
government and hybrids—that would be neither centralized nor anarchical
networks."
- I refer to these a human dimensions, left vs right brains; also
human intelligence centers informed by the heart (emotional
intelligence) and the brain (intellectual intelligence); also vertical
and horizontal – horizontal control is typically applied, to the
detriment of an organization, so there is top down control; adding a
vertical dimension means peer-to-peer and networking, very much how the
Internet works.
- this suggests, all at once, top-down, bottom-up, and side-to-side peer relationships.
- The only thing that can be achieved is a working balance, and we
succeed despite our personal liabilities. In that sense, no I don't
believe in "extreme programming." I believe in what works, as in what
emerges, sometimes through a methodical disciplined coding style
informed by a plan, and sometimes through a revolutionary insight that
forces a paradigm shift and upsets the working order.
- The "agility" required to negotiate this, and remain balanced should be a prerequisite.
- I met Dean Hock when he introduced his concept of a chaordic
organization at an annual meeting for the Conservation Law Foundation,
and we have remained friends since.
- I met Dean Hock when he introduced his concept of a chaordic
organization at an annual meeting for the Conservation Law Foundation,
and we have remained friends since. Note that Dean is the founder and
former CEO of the VISA credit card association, a core banking
association.
Is Timothy Jenkin involved at all with CGB as I am sure someone here must be familiar with him? if not, perhaps he should be contacted and would be willing to be a consultant as he has created an IT system for his south african based local currency exchange. Found out about him through a Tom Greco interview I saw recently.
Yesterday I was trying to data-model the system. The Bank part is too simplistic (but maybe not so for presentation), but the DA part may be useful to start discussion. Using the Image tool button I got the dialog to paste an image below, but the browse button didn't bring up a dialog. Pasting in a local path didn't work so I'll email it to the team for now.
Darn. The Forum software has a bug apparently. I just upgraded to the latest version, but it still has that bug (plus some others). I have inserted the diagram image into the CGB Depositors Association Draft IT Plan. I guess for now we will have to use the documents rather than the forum for any images.
Since that diagram looked so forlorn in the otherwise empty DA IT Plan I cloned the Bank IT Plan outline around it, making only a few changes, adding appropriate comments to re-cast and simplify the various sections in light of the differences. I figured that that was a better approach than having to re-create the wheel from scratch.
Then I added extensive comments on Data Models, using them, reading them, and some specific comments on (some of) the features of this one that support specific functions of the DA and the Bank. (Not done yet.) While doing that I also updated the model some.
I appreciate the top-down logic of the procedure #1 about creating a diagram that shows all the business units relationships and then attacking the individual units. But I cannot grasp the relationships without trying to model some of the key details at the unit level. Every time I read that statement the picture was too fuzzy to draw. For me Data Modeling – guided by the business plan – is the surest and fastest way to understand how a system is supposed to work. Without the understanding derived from a real rigorous model the picture at the top is a meaningless (or at best, uncertain) pretty picture, of which I've seen too many.
Yesterday I was trying to data-model the system. The Bank part is too simplistic (but maybe not so for presentation), but the DA part may be useful to start discussion. Using the Image tool button I got the dialog to paste an image below, but the browse button didn't bring up a dialog. Pasting in a local path didn't work so I'll email it to the team for now.
Darn. The Forum software has a bug apparently. I just upgraded to the latest version, but it still has that bug (plus some others). I have inserted the diagram image into the CGB Depositors Association Draft IT Plan. I guess for now we will have to use the documents rather than the forum for any images.
Post edited 2:27 pm – November 3, 2009 by wspademan
Yesterday I was trying to data-model the system. The Bank part is too simplistic (but maybe not so for presentation), but the DA part may be useful to start discussion. Using the Image tool button I got the dialog to paste an image below, but the browse button didn't bring up a dialog. Pasting in a local path didn't work so I'll email it to the team for now.
Post edited 12:43 pm – November 3, 2009 by wspademan
Several of us are working together to rework the CGB IT plan. Here is the working document: CGB Draft IT Plan. Please feel free to comment. To see the plan you will need to create a free Google Documents account, if you don't have one already.
print page
Login 
Register 
Search 
Home
Add a New Topic
Reply to Post
Quote and Reply 
Print this Post 
Topic RSS 
