Credit Union Mergers – Mitigate Technical Risk

March 18, 2009

From my point of view a credit union merger is a ‘non-trivial’ event, however I am excited about the opportunity that this provides both entities from a technology perspective. A small credit union can come out of a merger stronger, leaner, and more efficient than before. This is an opportunity to streamline, achieve economies of scale, and combine the best of each entity while discarding the unworkable elements. The following are a list of good questions to ponder with your teams. Here is a short list of what I would consider to be the ‘tough stuff’ from a voting and discussion perspective between teams.

Technical Systems Integration Planning Steps

  • What is the plan for the coexistence of two (separate) LAN and WAN networks and what is the end state goal?
    •  IP Scheme – bridged/ routed network
    • Are the Credit Unions using disparate core systems? Different Versions? Do they have conflicting IP Scheme requirement?
  • What are the deadlines that need to be hit so that they details can be coordinated?
    •   IP Scheme
    •  Printing (Sharing, Services, Drivers)
    • Bandwidth
    •  Routers
  • What is the plan for the convergence of credit union peripheral hardware convergence?
    • Signature pads
    • Receipt Printers
    • Scanners
    • Check printers 
  • How will imaging be merged, including the old that may need to be kept for 7 years? What is the plan for current and historical images? What is the final imaging goal?
  • How will old core system records be kept (Core historicals, etc.)?

Internal Questions

  • What is the end network design?
    • WAN Architecture
    • Integration
    • POP Diversity
    • Redundancy
    • Encryption
    • QoS – quality of services to protect VoIP integrity
  • Can the credit unions use each other for DR?
  • What services will be shared?
    • Active Directory
    • Email
    • Files
    • SQL Databases
    • Domain Controller Authority
    • Imaging
    • Domain Trust
      • Is Microsoft SBS involved? If yes, there are important trust planning considerations.
  • Will Microsoft licensing be audited to take advantage of consolidation? Use a merger to negotiate and consolidate licensing.
  • What is the plan for enterprise back-ups long term?
  • How will the phone system be consolidated and converged?

So here is the summary of my merger material. I have collaborated with a couple of team mates to put this 2 part series together for everyone. I hope you like it and that it was useful to you.  

 

Advertisements

Considering a Merger? Is the Time Finally Right?

March 5, 2009

With the economy shifting south, coupled with the NCUA assessment fee to bail out the Corporate Credit Unions, small credit unions can combine forces to compete better and provide more value to their membership. I am observing a trend toward small credit unions merging on a much more rapid scale than I have seen in the past. The merging of credit unions is not noteworthy in and of itself, however I do believe that mergers that combine to reach the $100 million plus range are going to increase.

 

When considering a merger, it is critical to establish relationships with experts you can turn to if you go forward. These experts should span all operations in the credit union, and be able to weigh in on questions such as:

 

· What are the best practices in merging a credit union?

· How do you merge IT departments without adding risk?

·  How to plan for and cut waste during a merger?

·  How can risk be mitigated?

·  What is the best way to leverage the opportunity to build in efficiencies?

· What functions can be strategically outsourced?

· What processes can be integrated?

· How should IT integration be handled?

 

Credit Union Merger Questionnaire – Information Technology

The following questionnaire pertains to the last point, and represents the starting point for planning and implementing effective IT integration for a credit union merger. These questions are intended to bring up important issues that must be planned for in the IT space, and to start discussions that will lead to effective decision making.

 

High Level Objectives/ Co-Existence Plan

  • Is the objective for the merger:  To attain one united front or identity with the leveraged strength of a partnership……
  • or is the goal of the merger to  maintain dual identities with the leveraged strength of a partnership?  
  • What is the plan for the existing domain names and the new domain name? Is there a timeline set for the old.org sites to disappear and one new.org to replace them, or will the old sites remain in place?
  • What is the plan for the email utility in the new entity? What is the timeline for implementation? Will there be coexistence of emails between domains?
  • How will home banking be presented to the members? What is the timeline for the change?
  • What SSL Certificates can be merged, deleted and/or re-used (web sites, ssl vpns, etc.)?
  • Is there a common encryption policy for sending information to third parties ( e.g. credit card processing via PGP, or does one of the entities have ZIx email encryption)?
  • What is the encryption goal? Are there any vendors that require specific encryption technology?
  • What is the end goal for the phone system and call center/ member services? Is there a timeline set for the convergence of the systems?

o        PRI analysis – what is the call routing plan?

o        Are you launching with core phone system functionality first and then integrating Call Center functionality after the merger?

 

  • What is the goal for integration and collapse of the networks (WAN – MPLS)? Applications  (like imaging, etc.)? Data bases? Other elements?

o        Has a cost analysis been completed for the infrastructure WAN collapse of the two entitities? Data, Voice (long distance/local)

o        What questions does one need to ask when integrating carriers – Sprint, ATT, Qwest, Verizon, and Paetech for example? (This blog link is an overview of questions to ask. http://itcustrategy.com/category/mpls/)

 

  • How are third parties (PSCU, FedLine, DI, etc. ) being addressed? Which third parties will remain? Are there redundancies? Which ones are going away? 

 

On my next post I will examine most technical questions that I have to ask myself when helping a credit union during a merger. 

 

 


Device-Focused MSPs Fail to Deliver Comprehensive IT Solutions to Credit Unions

January 1, 2009

I have had it with big companies attempting to monitor and manage small to medium business. Dell, HP, Ingram, and the list goes on, are now offering programs that only local businesses can deliver in a quality manner. And now Sonicwall has rolled out a managed security service. 

I am disheartened to see big vendors getting into Managed Services Programs (MSP). Big companies that stand up NOCs (somewhere) and try to deliver quality MSP services are not the route to success for a credit union. 

Credit Unions need to consider the following when selecting a good MSP:                                                                                     

  • How is third party due diligence  (covering insurance coverage, hiring, security controls, financials, etc.) handled? If your hard working IT manager has to rattle around to his vendors for this information then you have the wrong vendor.
  • What is the Disaster Recovery plan of the MSP? How can they help you?
  • How do they cover compliance and infrastructure?
  • Who owns them? Are they absent or involved?
  • Are they focused on growth for growth’s sake? Is there a reason for growing? What are their plans to handle growth?
  • Is the MSP focused on device management or is the MSP focused on being a trusted partner that will support the credit union from Architecture and Design all the way to Tier 1,2,3 IT operations support? 

I own a local MSP business that supports credit unions, and I strongly believe a credit union must partner with an MSP provider who has a vested local interest in the industry, the market, compliance needs, and all the other details and complexities that tend to escape large companies attempting to shoehorn “one size fits all” into the market. 

In my humble opinion, manufacturers of IT products like HP, Dell, Ingram and Sonicwall, should focus on building great products and less on delivering Managed Services.


Managed Services for Credit Unions: The Difference between Surviving and Thriving

December 15, 2008
When I search the internet, I see virtually no mention of managed services in the credit union space. This surprises me. 

I hear too many credit union CEOs wonder how to survive. I offer an alternative vision for what is possible for your credit union: Thriving. 

And I assert that any credit union from $20 million to $200 million in assets must be using a Managed Services Provider in order to thrive.  

Think this is a bold statement? Perhaps it is. Let’s look at the facts before you decide. 

Small to small/mid credit unions are faced with managing a level of IT complexity that no other business of the same size must manage (other than, perhaps, health care). The complexity is created because of five requirements: 

  1. Compliance
  2. Security
  3. Third party relationships (e.g., ATMs, Shared Branching, Home Banking, Core Processing, Fedline)
  4. Disaster Recovery
  5. Infrastructure Operations 

No small to small/mid credit union can effectively manage IT through in-house staff alone.  Staying focused on driving member value is critical. Diverting the IT department to review  and maintain “plumbing systems” when they could be reviewing, implementing, and evaluating systems that enhance the value of the credit union in the eyes of the members–that is where IT has to be focused. Resource coverage in the areas mentioned above is too challenging, and too risky to try with only in-house staff. 

In the IT space, a step that supports thriving is outsourcing your IT operations. Hire a Managed Service Provider (MSP) who can handle all the blocking and tackling of the five items I listed above. 

I have noticed that a credit union that has reached over $100 million in assets typically has one person on the IT staff who is smart and capable. Without an MSP in place, this person invariably ends up trying to do everything. Rather than tying up this valuable resource on housekeeping chores, have your MSP report monthly to this person. Require that the reporting be compliance based in nature and not all technical; if this is not required then you are still saddling your key IT Manager with the burden of producing the proof needed each month. 

I can’t stress this point enough: Shift your key manager’s focus to member-facing projects and have the MSP deliver the rest. This will put the company on the road to thriving and, from a professional growth perspective, it places your “shining star” IT employee in a position of managing the plumbing versus doing the plumbing, which should be a welcome step up for any bright, ambitious manager.

 


What’s Wrong with This Picture? (and How to Put It Right)

November 15, 2008

 

“I’m the CFO, it’s not my job to worry about IT.”

 

I have noticed an interesting trend over the past several months that I find exciting. This is the heavy involvement of Finance (Controller and CFO) in IT, not just in decision-making and approvals of IT investment, but in the strategic planning process. I am very encouraged by this.

 

If your senior financial management is not involved in the IT function of your company, I strongly suggest that you consider fixing this situation. Here is a cautionary story that illustrates the problems that a company can face when it doesn’t involve non-IT decision makers in the IT planning process. It illustrates why the CFO must care.

 

We had a non-credit union client recently who was experiencing tremendous pain around complaints from a user community of about 350 users distributed over 14 sites. They had just had a turnover of IT management at the highest level, and this is where I got involved.

 

The user community complaints were actually a symptom of a much deeper and more serious issue.  In the course of our engagement with senior management, we uncovered eight years of executive management neglect of the IT function. It wasn’t malicious neglect; it was unintentional neglect that arose from a lack of a vision, strategy, and long term IT roadmap upon which to base financial and management decisions. There had been no involvement of non-IT executives; as such, IT was not aligned with business vision or strategic objectives.

 

How did this happen? How did they get themselves into this predicament? Here are two examples among several:

 

  1. Their WAN was creaky and old (one of the oldest I have ever seen), but there was no attention on uplifting the infrastructure as part of an iterative and ongoing strategy. A major core business application was rolled out to all sites across , and since no attention was paid to shoring up the infrastructure before application installation, infrastructure performance took a steep (and problematic) drop.
  2. The company was encouraged by their VoIP vendor to purchase a brand new VoIP system. Three integrators later, they were left with the most complicated VoIP routing and switching installation I have ever seen. To make matters worse, they have never received the expected value from the investment.

 

The good news is that we are working with management to fix things. The company must now allocate significant spending to IT in order to make up for the years of little to no investment in infrastructure, disaster recovery, compliance, and other key program components. Though this is a somewhat bitter pill to swallow, it has had the good result of gaining the CFO’s attention and interest.

 

The new IT goal set collaboratively by the IT manager, the CFO, and the Controller is stable, simple, and maintainable systems that produce happy users. They wanted a high quality ‘austere’ network—not “cheap,” but “no frills.”

 

This company also made the decision to go with a Managed Services Provider (MSP) as part of a strategic move to focus their limited but talented IT resources on core business activities. They determined that as far as third-party relationships, they didn’t want a tactical IT partner—that is, a provider that only manages a device or set of devices. They wanted a partner that would participate in strategic planning, design, and architecture, as well as a partner who could assist them in day-to-day management of sophisticated devices from Tier 1-Tier 3 support.

 

Areas that we recommended they turn over to an MSP encompassed much of the security infrastructure, including the DMZ, firewalls, SPAM filters, SSL VPN, Load balancers, QoS devices, AD, Servers, and Consolidated Event Management. (The caveat, of which they are cognizant, is that an MSP can only be brought in after their infrastructure has been assessed and remediated.) Hiring and managing the in-house talent to effectively support all the equipment listed above would run $80-110k per year; the MSP we recommended performs the same services for $48k per year.

 

One of their primary goals, right after end user happiness, is network stability for the VoIP system. We encouraged them to focus on simplicity in order to make the network able and supportable. Since they had determined that they did not want their core IT staff supporting a non-business value add system then this system also had to be simplified so that the MSP taking over the VoIP management wasn’t saddled with the same issues.

 

We continue to work with senior management on effective IT strategy. As far as next steps, the CFO wants an IT roadmap, that is, a doable plan that is sized right for the company. Immediate action items include:

 

  1. Data Center power distribution and re-cabling.
  2. Replaced the 10-year-old ATT WAN with a new Sprint MPLS WAN.
  3. Virtualization (there is no more server rack space left)
  4. Disaster recovery site implementation
  5. Employing a different back up method from the tape backups currently being used.
  6. A comprehensive Microsoft licensing strategy that includes an audit of current licenses.

 

My reason for providing a high level of detail in this story is to give you clear examples of IT issues that may track with your own. If any of the problems or strategies that this client is dealing with ring any bells for you, it may be time to examine your own IT function and how your financial management relates to it. If your senior financial manager is not getting involved with IT strategy or decision making, you may want to better align the two. If you don’t, there may be trouble brewing behind the scenes.



Making the case for Single Sign On (SSO) and Biometric authentication

May 15, 2008

I started to discuss Enterprise Single Sign On (ESSO) with credit unions three years ago, and since then I have been to Burton Group to learn about Identity Management from the inside out. I learned about how I could integrate identity management with existing security practices for “budget constrained” credit unions. The key that I was looking for was a simple, easy, and properly built solution that could be integrated into medium-to-large credit union environments for less than $25,000-$35,000 — including services. I was looking for non-script based and non-programmed solutions since I knew that cost escalation would kill SSO efforts for credit unions very quickly.

Definitions:

Enterprise Single Sign On (ESSO) – ESSO is simple since it is a non-programmed way to handle SSO, thus making it much easier and less complex.

Single Sign On (SSO) SSO is a programmed method of performing SSO with the key difference of having the added functionality to handle forced role-based authentication directly into applications themselves from the network. This is the Holy Grail – for the big boys and serious budgets!

I look at ESSO as “the poor man’s single sign on”, however don’t be fooled into thinking ESSO is of lesser quality to SSO. ESSO is incredibly powerful and quite a compelling approach to what I would call “Reduced Sign On” versus “Single Sign On”. Credit Unions should consider ESSO/SSO options when experiencing the following problems or increased needs:
1) The help desk is having to handle too many password reset requests. I once worked with a credit union that justified costs due to this issue alone.
2) IT (believe it or not) is handling an extraordinary number of passwords.
3) The desire exists to integrate physical and network security (very cool and doable these days).
4) Compliance Drivers, meaning you have a desire to monitor, track and perform forensics on network and application access.
5) A need for increased security due to IT being unable to enforce a demanding password policy.
6) A need for increased security that will not see employees leaving passwords lying around their office on notepads.
In summary there is the coolness factor to SSO and ESSO, but for me the credit union winning punch here is the compliance win and the ability to integrate biometric authentication with the solution. I am not sure I believe entirely in the concept of SSO and this is why I like ESSO since the application still drives the final layer of security.

ESSO has the ability to layer biometrics on top of the authentication, making it an appealing solution since one gains the compliance uplift, plus the added “I know who you are” factor from the biometric stand point. Ultimately, my vision has always been to concentrate on the directory security needs in an organization. For my credit union clients this is usually accomplished via Microsoft’s Active Directory. From a de-provisioning perspective, it is quite appealing that once a user account is killed in AD then they are in effect “locked out” of the network. It is very nice indeed to have all devices on the network just as directory-aware. Furthermore, if you are allowing Citrix or another remote access, this centralized AD security approach works well since once an employee or contractor is terminated then all IT must do is terminate the account in AD and the remote access is terminated as well. For credit unions with overburdened IT personnel this makes for simple, effective and clean security.


Implementing an IT Disaster Recovery Plan That Works (Part 2)

May 3, 2008

Here’s another story of a larger credit union client of mine.

The credit union said to me one day: “Bill, we have all this stuff and my staff if good. How do we pull all this software and hardware together into a comprehensive Disaster Recovery program?” Over the past two years, the credit union had acquired the following:

  • Fatpipe load balancers;
  • VMware;
  • Backup software (Issue: tapeless versus traditional? They were partial to tapeless);
  • Doubletake;
  • Platespin;
  • HP NAS appliance;
  • iSCSI SAN from Lefthand;
  • DR Site;
  • Connectivity;

The executive summarized his predicament to me like this: “the products all appear to be good.” I agreed, but based on his current network problems, tight back-up windows, huge WAN latency and more, it appeared that several of these products had overlapping functionality causing them to argue and step on each other. “There is no way I can roll this out into production without being sure” he said.

The credit union asked me to come up with solutions in several areas, in particular the executive wanted answers to these questions:

  • How can they repurpose the HP NAS so that the investment is not wasted?
  • What is the best way to use the iSCSI SAN from a block level replication perspective?
  • How is back-up and corruption protection going to be handled?
  • What function will Doubletake play in the new design?
  • How will the WAN network respond to the new design? The credit union had a combined MPLS and point-to-point architecture.
  • Why are backups barely being completed overnight? This could be indicative of bigger issues that need to be solved first.

For larger credit unions, one must approach back-up differently, often through production uses of a SAN.

The following summary of questions will help you understand Disaster Recovery as two necessary categories including 1) backup and correction protections and 2) production SAN and virtualization.

These two categories are what I explore with clients in the process of determining the exact level of customization required for their DR environment.

Backup and Corruption Protections

1. Do you want to keep managing backup tapes for Microsoft systems, core systems, imaging systems? You should know the costs for this process (for example, Iron Mountain)

2. What is the risk for this process? You might consider losing tapes, theft, or other eventualities.

3. If you move to a tapeless system what is the local restore capability?

4. What about “in the cloud” solutions? There are some cool ones that work really well.

5. Does your backup solution provide local corruption protection?

6. If I make a call to Microsoft for support will they take my call?

7. Will the tapeless solution recover the O/S of the core processor? The only answer is no, so are you really tapeless?

Production SAN and Virtualization

1. Why do I need virtualization and an iSCSI SAN?

2. Why is virtualization perfect for my day-to-day operations?

3. Why is virtualization a ‘magic bullet’ for my DR initiatives?

4. What are the downsides of virtualization?

5. How do I know if I can virtualize a system?

6. How do I assess the readiness of my virtualization?

7. What about Microsoft systems that are iSCSI aware? SQL 2005 and Exchange 2007 are both options. You should consider how this might change your iSCSI SAN and virtualization objectives.

That’s enough information to get you started on the path to implementing an IT Disaster Recovery Plan that works. (See my previous post for questions related to a smaller credit union.)