65 lines
3.2 KiB
Markdown
65 lines
3.2 KiB
Markdown
---
|
||
type: "topic"
|
||
created: "2024-01-06T01:25:36.182Z"
|
||
updated: "2024-01-06T01:25:36.182Z"
|
||
---
|
||
|
||
# Continuous Improvement - next steps
|
||
|
||
Hi All
|
||
|
||
Please look at the next steps and have feedback ready.
|
||
|
||
## Next steps
|
||
|
||
- Review and feedback of Incident Frequency actions. Outline attached
|
||
- Ideas on how we want those practices documented
|
||
- Start roadmap of how establish consistency across all apps
|
||
- For reduction in Requirements Changes; - Consider requirements documents examples. What is a good fit for our sites. Marti will send some examples. - Decision / assumption is all requests should have a requirements doc assuming it can be simple for small enhancements
|
||
- Marti to prepare for AO roles and responsibilities for next staff meeting. Should jump into this earlier rather than later.
|
||
|
||
## Key Metrics – value add
|
||
- Incident Frequency – increase quality and stability with permanent corrective actions/detections
|
||
- Outline actions/practices
|
||
- Check for sustainability / gaps
|
||
- Next steps
|
||
- SLA for Critical and High priority incidents – minimize factory impact of application failures
|
||
- follow FI Problem Management process for SLA violations
|
||
- review session for updated process
|
||
- Performance to Commit – increase customer satisfaction with on-time delivery of high priority enhancement requests
|
||
- Update graph to include number of requests completed
|
||
- Outline current / needed practices
|
||
- Align on where to start
|
||
- Check for sustainability / gaps
|
||
- Next steps
|
||
- Deployment Quality
|
||
- Outline after AO responsibilities and define IRMA scope
|
||
|
||
## INCIDENT FREQUENCY
|
||
|
||
- Practices to keep and expand. Define gaps and outline next steps needed.
|
||
- For all in-house apps.
|
||
- Join all apps in Iteraplan to Eva
|
||
- Source Control in Git
|
||
- Use of Dev server for development
|
||
- Use of DevOps
|
||
- Join all apps in Iteraplan in Eva
|
||
- Build script to build binaries (how to accomplish the same for OI); adjust for Test environment; incl diff levels of complexity where possible
|
||
- Include automated test plans; minimum “happy path”
|
||
- Script to release/deploy - Rigorous testing; more edge cases, use checklists and/or OneNote, may be in Test Plans - Code review before deployment - User testing and buy-off before deployment - Ensure user training is done before deployment - Communication (customer and FI) before deployment. Leverage IRMA - App / Server monitoring; define standard minimum resource/behavior to monitor.
|
||
- For 3rd party apps (no development but vendor or Infineon upgrades)
|
||
- Join all apps in Iteraplan to Eva
|
||
- No source control and no Dev server
|
||
- No use of DevOps due limited benefit
|
||
- User testing and buy-off before deployment
|
||
- Ensure user training is done before deployment
|
||
- Communication (customer and FI) before deployment. Leverage IRMA
|
||
- App / Server monitoring; define standard minimum resource/behavior to monitor.
|
||
- For Marti;
|
||
- work on retaining/developing OI / Mesa OI experience
|
||
- ensuring that scope/size does not exceed FI resource bandwidth
|
||
- Continued communications with IT OS (bi-weekly alignment call)
|
||
- Work with team to propose best fit FAQ solution
|
||
- Consider customer enabling as part of PCA
|
||
- How and where to enshrine
|