IT strategy: Difference between revisions
Jump to navigation
Jump to search
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
Ground up IT strategy | Ground up IT strategy | ||
=== | ==Constraints== | ||
===Resources=== | |||
There is a marked lack of financial and HR resources to implement new systems: | |||
*To buy new IT (Bottom line expense) | |||
**To configure for use | *To package/maintain/install IT (Technology resource) | ||
*To configure new IT for UBS (Technology resource) | |||
*To configure for use by legal (Legal/Technology resource) | |||
*To train users (internal Legal/Technology resource) - do not underestimate the importance and difficult of this | |||
NB: users who are legally and technically literate are '''rare'''. | |||
===Institutional Problems=== | ===Institutional Problems=== | ||
====The Meatware==== | ====The Meatware==== | ||
*User intransigence | *User intransigence | ||
**technological: don’t understand/like new technology | **technological: don’t understand/like new technology; significant change fatigue | ||
**Technical: | **Technical: Our skill is creating and articulating bespoke solutions, not commoditising standard ones. | ||
**Lawyers don’t write well. Legal drafting is convoluted, over particularised | **Lawyers don’t write well. Legal drafting is convoluted, over-particularised and prone to negotiation and error | ||
*User knowledge is imperfect | *User knowledge is imperfect | ||
**Individuals who don’t understand policies are incentivised to apply them literally (being institutionally short an option - see below) | **Individuals who don’t understand policies are incentivised to apply them literally (being institutionally short an option - see below) | ||
Line 19: | Line 23: | ||
*Institutional knowledge is poor | *Institutional knowledge is poor | ||
**We don’t track our decisions - no MI kept on litigation close shaves; which issues come up and which don’t. | **We don’t track our decisions - no MI kept on litigation close shaves; which issues come up and which don’t. | ||
*Legal department’s institutional position: Being a control function, Legal is “short an option” | *Legal department’s institutional position: Being a control function, Legal is “short an option” | ||
**Important to | **We are not rewarded for approving successful business; | ||
**We are criticised for approving business which encounters any legal issues. | |||
***Important to differentiate legal and commercial issues and allocate ownership correctly. (e.g.: indemnities are, ultimately, commercial and not legal issues) | |||
====The firmware==== | ====The firmware==== | ||
Line 39: | Line 45: | ||
**“Business Data Catalogs” to interrogate external databases from within Sharepoint | **“Business Data Catalogs” to interrogate external databases from within Sharepoint | ||
**Application Interfaces (“API”s) | **Application Interfaces (“API”s) | ||
*Open source solutions - There is a lot of good, free software available (e.g. MEdiawiki) | |||
*You have to spend to save: Some technology is worth investing in. | |||
===There are benefits to doing things differently=== | |||
We are in a new world, and we should upgrade our practices to take account of it: e.g. Electronic execution, | |||
*collects audited information about the time and date of execution | |||
*documente assembly naturally stores documentation and collects key metadata about the variable content of the agreements | |||
===Challenge=== | |||
*First: clean up: it is much easier to automate a simple structure than a complicated one. Simple structures are more scalable, less prone to error. | |||
*Small projects: See above. Be unambitious. Small, unglamorous projects save resources incrementally and buy time for projects. | |||
**e.g., Confidentiality Agreements | |||
*Co-ordinate: each project should be managed separately, but users should be encouraged to share technology, and build on each other’s work - centr | |||
__NOEDITSECTION__ | __NOEDITSECTION__ | ||
__NOTOC__ |
Revision as of 12:06, 4 December 2016
Ground up IT strategy
Constraints
Resources
There is a marked lack of financial and HR resources to implement new systems:
- To buy new IT (Bottom line expense)
- To package/maintain/install IT (Technology resource)
- To configure new IT for UBS (Technology resource)
- To configure for use by legal (Legal/Technology resource)
- To train users (internal Legal/Technology resource) - do not underestimate the importance and difficult of this
NB: users who are legally and technically literate are rare.
Institutional Problems
The Meatware
- User intransigence
- technological: don’t understand/like new technology; significant change fatigue
- Technical: Our skill is creating and articulating bespoke solutions, not commoditising standard ones.
- Lawyers don’t write well. Legal drafting is convoluted, over-particularised and prone to negotiation and error
- User knowledge is imperfect
- Individuals who don’t understand policies are incentivised to apply them literally (being institutionally short an option - see below)
- Institutional Knowledge: Generally is good (UBS turnover is comparatively low) but we leak institutional knowledge and it is not tracked and captured.
- Institutional knowledge is poor
- We don’t track our decisions - no MI kept on litigation close shaves; which issues come up and which don’t.
- Legal department’s institutional position: Being a control function, Legal is “short an option”
- We are not rewarded for approving successful business;
- We are criticised for approving business which encounters any legal issues.
- Important to differentiate legal and commercial issues and allocate ownership correctly. (e.g.: indemnities are, ultimately, commercial and not legal issues)
The firmware
- Bad static data (inaccurate; unreliable)
- Bad legal standards (overcomplicated; commercially unrealistic; out of date)
- Bad templates (too many; overcomplicated; inconsistent; out of date)
- Bad taxonomies
Opportunities
- Data we don’t use: All historical departmental email: - a rich source of indexable institutional knowledge - this resource should not be restricted to use in conducting.
- Underused/misunderstood existing tools -
- Sharepoint
- Microsoft Word/Excel
- Workshare
- Opportunities to enhance/improve existing tools
- TADH
- Easy implementation to enhance interaction and connectivity
- “Business Data Catalogs” to interrogate external databases from within Sharepoint
- Application Interfaces (“API”s)
- Open source solutions - There is a lot of good, free software available (e.g. MEdiawiki)
- You have to spend to save: Some technology is worth investing in.
There are benefits to doing things differently
We are in a new world, and we should upgrade our practices to take account of it: e.g. Electronic execution,
- collects audited information about the time and date of execution
- documente assembly naturally stores documentation and collects key metadata about the variable content of the agreements
Challenge
- First: clean up: it is much easier to automate a simple structure than a complicated one. Simple structures are more scalable, less prone to error.
- Small projects: See above. Be unambitious. Small, unglamorous projects save resources incrementally and buy time for projects.
- e.g., Confidentiality Agreements
- Co-ordinate: each project should be managed separately, but users should be encouraged to share technology, and build on each other’s work - centr