Прототип корпоративного ПО с интегрированным клиентским порталом
Бакалаврская работа о пользователе-ориентированном анализе, гибком планировании и технической разработке ERP/портальной платформы для процессов переработки.
Работа связала Double Diamond, Scrum и DevOps для проектирования ERP-близкого ПО с клиентским порталом, OCR и цифровым процессом приёма/взвешивания, проверенного опросами, интервью и шестью спринтами.
Исследование кратко
149
Survey responses
Customer and stakeholder feedback on digital service expectations
91
Requirement matrices
Structured requirement and prioritisation artefacts
17
Roles
Role model covering internal and customer-facing access
6
Sprints
Scrum increments for planning and implementation
132
Database tables
Data model breadth for ERP-near processes
5
Languages
Multilingual readiness of the portal concept
✓
Interviews
Qualitative validation with operational stakeholders
1
Intake process
End-to-end digital weighing/intake process designed
Проблемы
Opaque prices
Solution: expose contract and price documents in the portal with clear validity context.
Missing documents
Solution: centralise weighing slips, contracts and invoices for on-demand retrieval.
Weak data quality
Solution: enforce structured intake fields and reduce retyping across media breaks.
Weighing mismatches
Solution: link declared vs. measured weights and support claim workflows digitally.
Limited yard control
Solution: use digital intake steps and yard lists for better on-site visibility.
Waiting times
Solution: pre-announce deliveries and streamline check-in before the scale.
Staff absence fragility
Solution: role-based access and shared digital records reduce single-person dependency.
Invoice chasing
Solution: searchable invoice archive with PDF download in the customer portal.
Capacity uncertainty
Solution: disposition views and booking signals for containers and time windows.
Low process visibility
Solution: status-oriented portal screens for intake, weighing and follow-up.
Исследовательские вопросы
Q1 – User needs
Which customer and internal needs should an industry portal address first?
Q2 – Method fit
How can Double Diamond, Scrum and DevOps be combined for this context?
Q3 – Process design
How should a digital intake/weighing process be structured end to end?
Q4 – Technical feasibility
Which architecture, data model and tooling enable an ERP-near prototype?
Q5 – Value and limits
What benefits are plausible, and which limitations remain for production rollout?
Методологическая модель
-
Briefing
Clarify company context, constraints and success criteria with stakeholders.
-
Analysis
Discover needs via interviews, survey, process mapping and competitor/SWOT views.
-
Planning
Translate insights into backlog, roles, epics and sprintable increments.
-
DevOps development
Implement, integrate, test and deliver the prototype in short cycles.
Цели
Support revenue quality
Reduce leakage from mismatches, claims and delayed documentation.
Reduce manual effort
Replace repetitive phone/email document handling with self-service.
Acquire and retain customers
Offer a modern digital channel alongside personal service.
Increase satisfaction
Improve transparency of prices, documents and intake status.
Ease staffing pressure
Lower interruption load on weighing and office staff.
Improve data quality
Capture structured data earlier in the intake chain.
Speed up intake
Shorten waiting and processing time through pre-capture and OCR support.
Выводы интервью
Role clarity is essential
Access and responsibilities must mirror real yard and office roles.
Multi-site reality
Processes differ by site and must remain configurable.
Interfaces dominate effort
ERP and peripheral system connections are critical path items.
Forecast demand exists
Planning quality depends on earlier, cleaner intake signals.
Double work is common
Media breaks cause repeated entry of the same facts.
Integration over isolation
A portal only creates value when tightly linked to operational data.
Результаты опроса
| Statement | Score |
|---|---|
| App-based delivery of documents | 4.30 |
| Digital access to weighing slips | 4.22 |
| Online invoice archive | 4.15 |
| Transparent contract and price documents | 4.08 |
| Status visibility for deliveries | 3.95 |
| Appointment and container booking support | 3.88 |
| Mobile usability on site | 3.76 |
| Master-data self-service updates | 3.64 |
| Quality and quantity reports | 3.51 |
| Chat/contact escalation when needed | 3.42 |
| Personal service remains important | 3.28 |
| Acceptable waiting time at weighing | 3.10 |
SWOT-анализ
Strengths
Domain proximity, existing practical-project foundation and clear operational pain points.
Weaknesses
Prototype depth limits, integration complexity and dependency on data quality.
Opportunities
Self-service growth, better intake data and scalable modular extensions.
Threats
Change resistance, security/compliance demands and competing tool expectations.
Разработанное ПО
ERP-near scope
Enterprise software spanning portal, intake and supporting operational entities.
Modular build
Feature modules aligned to weighing, disposition, documents and administration.
Portal UI
Role-aware screens for customers and internal users across devices.
Pricing/documents
Structured handling of contracts, prices and related PDF artefacts.
Цифровой процесс приёма
-
Step 1 – Pre-announcement
Customer announces delivery with material and timing context.
-
Step 2 – Slot / capacity check
System checks feasible intake windows and yard capacity signals.
-
Step 3 – Digital check-in
Arrival is registered before or at the gate with required identifiers.
-
Step 4 – Document capture
Delivery notes and IDs are captured via form and/or OCR.
-
Step 5 – Yard list assignment
Vehicle/load is placed into the operational yard list.
-
Step 6 – Visual inspection
Material quality checks are recorded against the intake case.
-
Step 7 – Weighing
Weights are measured and linked to the digital intake record.
-
Step 8 – Variance handling
Declared vs. measured differences trigger guided follow-up.
-
Step 9 – Confirmation
Customer and internal roles receive confirmation artefacts.
-
Step 10 – Claim path
Complaints/claims can be opened with linked evidence.
-
Step 11 – Posting preparation
Clean intake data is prepared for ERP/accounting follow-on steps.
-
Step 12 – Archive & analytics
Documents and metrics remain retrievable for controlling and service.
OCR и машинное обучение
OCR for intake documents
Optical character recognition to reduce manual retyping.
Role: Assistance with human review — not unsupervised posting.
Limit: Prototype-level accuracy; production tuning still required.
ML support concepts
Machine-learning ideas for classification and prioritisation support.
Role: Decision support for staff, with confidence-aware review.
Limit: Partial conceptual/prototypical coverage only.
Результаты
Method chain validated
Briefing → analysis → planning → DevOps worked as an integrated model.
User-first requirements
Survey and interviews grounded prioritisation in real needs.
ERP-near prototype
Broad data model and modular features approached industry ERP workflows.
Digital intake designed
A 12-step weighing/intake process was specified and prototyped.
Digital openness confirmed
Customers showed willingness to use digital document and status services.
Personal service still critical
Digital channels must preserve escalation to human support.
OCR assistance feasible
Document capture can reduce typing when paired with review.
ML as assistive layer
Machine learning is most credible as staff assistance, not full automation.
Ограничения
No long-term rollout study
Adoption over months/years was outside thesis scope.
Breadth vs. depth
Wide process coverage limited deep hardening of every module.
OCR as proof of concept
Recognition quality was not production-certified.
Partial ML scope
ML features remained conceptual/prototypical.
Survey scope limits
Results are context-bound and not industry-representative.
Service expectation risk
Poor digital UX could harm perceived service quality.
Security depth
Full enterprise security hardening was not the primary deliverable.
Data model complexity
Large schema increases migration and governance effort.
Рекомендации
R1 – Start with documents & intake
Prioritise weighing slips, invoices and digital check-in for early value.
R2 – Keep humans in the loop
Design escalation paths beside self-service.
R3 – Fix media breaks first
Remove retyping before adding advanced analytics.
R4 – Role-based rollout
Introduce features by role and site.
R5 – Integrate, do not isolate
Connect portal writes/reads to ERP master and transactional data.
R6 – OCR with review UX
Ship OCR as assisted extraction with confidence display.
R7 – Measure after pilot
Define KPIs and measure in a controlled pilot.
R8 – Security & tenancy early
Treat access control and tenant separation as release blockers.
R9 – Keep DevOps discipline
Retain CI/CD and environments while the system grows.
R10 – Plan AI as next layer
Use cleaned intake data as foundation for later AI assistance.
Технологический стек
Backend
Frontend
DevOps
OCR / ML
Линия развития
-
2022 – Practical project
Initial DevOps cycle and portal prototype.
-
2023 – Bachelor thesis
User-centred ERP-near platform and digital intake process.
-
2025/2026 – Master thesis
AI use cases and NLP prototype for industry ERP processes.